# Clarification on type piracy

**URL:** <https://discourse.julialang.org/t/clarification-on-type-piracy/5926>\
**Category:** General Usage\
**Tags:** type, nemo, type-piracy\
**Created:** [September 16, 2017, 7:13pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926 "2017-09-16T19:13:53Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 7:13pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/1 "2017-09-16T19:13:53Z")

</div>

In the style guide, it talks about type piracy [1], the practice of extending or redefining methods on types you didn’t define. We’ve been told in the past not to do this, especially with methods and types defined by Base, as it can subtly break Julia.

However, we are in a situation where we really want to do this. The issue is with the Julia definition of the functions exp, log, inv, sqrt, sin, cos, tan (and other trig functions) and also det (for unrelated reasons).

We are writing an abstract algebra package which defines generic power series over any ring. In order for such power series functions to work, we must define all the functions above for the ring over which the power series are defined. This is ordinarily not a problem because we are defining them for types that we have defined.

One significant problem comes if we want to do power series over Julia types belonging to Integer or Rational. Here Julia defaults to the numerical standard of returning the result in the archimedean completion, instead of returning values in the original ring itself, as an algebraist would (if an algebraist wanted the value over a completion, they would specify which completion!). This implies that one simply cannot define power series over Julia Integer or Rational types in a way that is useful to algebraists.

However, there is a solution to this. Within our module (Nemo), we can define all these functions ourselves, with the usual algebraists definition, without first importing them from Base. Anyone who uses our module will have to disambiguate, but this seems to be a small price to pay. Nothing can break, as Julia itself does not use Nemo.

But we want to check with the community whether this is acceptable, or whether it would be considered type piracy? Just to be clear, we are asking whether we can define Nemo.exp, Nemo.inv, Nemo.sqrt, Nemo.det, on Julia Integer and Rational types (without importing from Base of course).

(Aside: we have long had a similar issue with / for division of integers, but we’ve worked around this by defining a function divexact, which we’ve gotten used to over time. It seems there is no similar workaround for /, as operators are handled separately. It wouldn’t be practical for anyone to have to disambiguate the use of operators. It wasn’t such a big deal, since we had to define numerous kinds of division anyway: Euclidean division, exact division, creation of elements in the fraction field, etc. The only thing it really ruins is copy and pasting of pretty printed output back into the REPL.)

[1] [https://docs.julialang.org/en/stable/manual/style-guide.html#Avoid-type-piracy-1](https://docs.julialang.org/en/stable/manual/style-guide.html#Avoid-type-piracy-1)

---

<div class="post-metadata">

**Author:** ![Michael\_Eastwood](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/michael_eastwood/32/669_2.png) [@Michael\_Eastwood](https://discourse.julialang.org/u/Michael_Eastwood)\
**Post date:** [September 16, 2017, 7:48pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/2 "2017-09-16T19:48:53Z")

</div>

Type piracy only applies to extending methods you did not define to operate on types that you also did not define. For example

```julia
module Foo
foo(::Integer) = 1
end

Foo.foo(1) # 1

module Bar
import Foo.foo
foo(x::Int) = 2
end

Foo.foo(1) # 2

```

The key part of this example is that `Bar` was adding methods to `Foo.foo` instead of `Bar.foo`. This allowed `Bar` to change the behavior of calling `Foo.foo(1)`. If I was relying on `Foo.foo` to return `1`, then defining `Bar` just introduced a bug into my code. However, if you delete the `import Foo.foo` line, you no longer have a problem.

Similarly, `Nemo` can safely add `Integer` or `Rational` methods to `Nemo.exp` if you do not import `Base.exp`. As long as you do this, somebody calling `exp(1)` won’t suddenly have the behavior of the program change after `using Nemo`.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 16, 2017, 7:50pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/3 "2017-09-16T19:50:20Z")

</div>

Having local implementations is not type piracy, see the “extending or redefining” part.

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 8:07pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/4 "2017-09-16T20:07:48Z")

</div>

I should add that we would be exporting these functions. Certainly not import, just export. Still ok?

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 16, 2017, 8:08pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/5 "2017-09-16T20:08:52Z")

</div>

Yes, it is fine, but what is the gain of exporting them?

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 8:11pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/6 "2017-09-16T20:11:58Z")

</div>

There might be a way around it in some cases, but for example, we have to export exp from Nemo, because exp is a function defined on power series, not just on the rings over which you can take power series. Also, sqrt returning a float just isn’t much use to a user of Nemo. They will want Nemo.sqrt to return an exact value in the ring (if it exists), etc.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 16, 2017, 8:15pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/7 "2017-09-16T20:15:14Z")

</div>

Nothing of what you said explains why you need to export e.g. `exp`. The `exp` binding is already available by default since it is exported from `Main`.

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 8:22pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/8 "2017-09-16T20:22:21Z")

</div>

You are right. I think you just revealed a misunderstanding I have about what export actually does.

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 8:31pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/9 "2017-09-16T20:31:22Z")

</div>

Actually, on second thoughts, Julia has changed the name of so many of its functions so many times, I think we ought not rely on a “binding” for exp being available because of an export from Main. And who knows, maybe one day they get moved into a package, as happened with isprime, for example (this was a good thing for us, I’m not criticising).

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [September 16, 2017, 8:37pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/10 "2017-09-16T20:37:02Z")

</div>

It still doesn’t matter because your users will qualify with module name.

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 8:47pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/11 "2017-09-16T20:47:16Z")

</div>

Technically, yes. But for new users, we essentially rely on the ambiguity message emitted by Julia to teach new users that. Should Julia change the name of its function, users would have no idea why the function doesn’t work. I still think it is better to export it, and I don’t see any down side.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [September 16, 2017, 9:07pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/12 "2017-09-16T21:07:59Z")

</div>

It’s a little hard to tell what you’re doing, but I have a feeling that this might not be the right (or at least not the most julian) way of accomplishing your task. Do you really need a new function called `sqrt` which is not just another method of `Base.sqrt`? That is, can you not just do:

```julia
module MyModule

struct MyNumber <: Integer
  x::Int 
end

import Base.sin

sin(y::MyNumber) = 2 * y.x

end

```

?

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 16, 2017, 9:16pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/13 "2017-09-16T21:16:19Z")

</div>

For the first few years we did precisely this. But now our module is more widely used, people want to do things like define power series for Julia Integers and Rationals using our module. We recently made this possible through some (perfectly Julian) trickery, which gets around the fact that Julia integers and rationals are not part of our abstract type hierarchy.

Also, we found a bunch of bugs in our code when we did this, because it allowed us to generate more exotic test examples which are more likely to trigger bugs.

Also, we are now planning to split Nemo into two packages, one of which is pure Julia, that can be used by other people without the C library dependencies that Nemo has. We considered wrapping the Julia types, but after reading answers on stackexchange on how to handle this, we decided this is not the best solution.

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [September 17, 2017, 6:48am UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/14 "2017-09-17T06:48:09Z")

</div>

> [@wbhart](#):
>
> But for new users, we essentially rely on the ambiguity message emitted by Julia to teach new users that.

It seems like a bad API to rely on users reading and learning from error messages.

> [@wbhart](#):
>
> I still think it is better to export it, and I don’t see any down side.

The problem is that it is not enough for a user to use `Nemo.exp`, but uses of `exp` will also need qualification with `Base.exp`.

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 17, 2017, 11:15am UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/15 "2017-09-17T11:15:08Z")

</div>

There isn’t any risk of an algebraist wanting Base.exp on a regular basis.

The only other solution is to use different names for power series functions, e.g. exponential, logarithm, square\_root, inverse, sine, cosine, tangent, etc. However, so far, our users have absolutely refused to allow that change. They want the same names as Julia uses. So we have some constraints on possible solutions to this.

Either we don’t allow power series over Julia types, which kind of makes Nemo useless as a standalone Julia module, or we rename all our functions to something that isn’t very convenient to use or remember.

If there was another workable solution, I’d do it.

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [September 17, 2017, 12:00pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/16 "2017-09-17T12:00:23Z")

</div>

> [@wbhart](#):
>
> There isn’t any risk of an algebraist wanting Base.exp on a regular basis.

Well, who are you to decide which functions people are allowed to use?

> [@wbhart](#):
>
> The only other solution is to use different names for power series functions, e.g. exponential, logarithm, square\_root, inverse, sine, cosine, tangent, etc. However, so far, our users have absolutely refused to allow that change. They want the same names as Julia uses. So we have some constraints on possible solutions to this.

Since you already require `Nemo.exp` the solution is to document that the way to use `Nemo` is to qualify functions with `Nemo.`

> [@wbhart](#):
>
> If there was another workable solution, I’d do it.

See above.

---

<div class="post-metadata">

**Author:** ![smldis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/smldis/32/1735_2.png) [@smldis](https://discourse.julialang.org/u/smldis)\
**Post date:** [September 17, 2017, 12:05pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/17 "2017-09-17T12:05:25Z")

</div>

Could you avoid exporting by wrapping all the code scoped to use Nemo symbols …etc… in a `@nemo` macro that prepends all the symbols with `Nemo.` ?

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 17, 2017, 12:15pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/18 "2017-09-17T12:15:34Z")

</div>

> [@fredrikekre](#):
>
> Well, who are you to decide which functions people are allowed to use?

I’m trying to respond to two competing demands:

1. Allow Nemo to work as a standalone Julia module which applies to Julia types

2. Keeping the existing Julia function names for exp, sqrt, inv, det, etc.

Julia makes this impossible by insisting on a particular definition of math functions that doesn’t make any sense in the context of a generic algebra package. It should be necessary in Julia to import math (or using Math) similar to Python. But that isn’t going to happen, so whatever we do, we are going to require some kind of workaround. Those are just the givens.

> [@fredrikekre](#):
>
> Since you already require Nemo.exp the solution is to document that the way to use Nemo is to qualify functions with Nemo.

This is not necessary. It’s baked into the language that if you want to call a function provided by a given module, and it conflicts with someone else’s module, you have to disambiguate. We don’t need to explain that to Julia users. We may put a note in the manual about the functions Julia has already defined, but our experience is users don’t read the manual for every function they use. They try a bunch of things first. In this case, Julia will tell them what they need to do. At that point, if they choose to look up the Nemo manual, they will find the information they need.

> [@fredrikekre](#):
>
> See above.

The solution suggested earlier in the thread does not address 1 above. Moreover, we explicitly looked for answers to people who had asked how to handle this in the past, and they were told to use a Union of Julia types with their own types to solve this issue. This is what we’ve done and we wouldn’t look back. Clearly requiring Nemo users to have a special integer type isn’t a realistic solution.

---

<div class="post-metadata">

**Author:** ![wbhart](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wbhart/32/4714_2.png) [@wbhart](https://discourse.julialang.org/u/wbhart)\
**Post date:** [September 17, 2017, 12:21pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/19 "2017-09-17T12:21:54Z")

</div>

> [@smldis](#):
>
> Could you avoid exporting by wrapping all the code scoped to use Nemo symbols …etc… in a @nemo macro that prepends all the symbols with Nemo. ?

Serious question: I actually don’t understand why people would want us to NOT export our functions. Doesn’t it ordinarily make the package really difficult and annoying to use if you don’t export the functions?

Yes, we could implement some macro for our users that would prepend Nemo. But what would be the motivation to do this? I don’t understand why there would be a reluctance to export functions from a module in the first place. Isn’t it standard practice?

I feel like I am fundamentally misunderstanding what export is for!

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [September 17, 2017, 1:24pm UTC](https://discourse.julialang.org/t/clarification-on-type-piracy/5926/20 "2017-09-17T13:24:15Z")

</div>

From your top post:

> [@wbhart](#):
>
> However, there is a solution to this. Within our module (Nemo), we can define all these functions ourselves, with the usual algebraists definition, without first importing them from Base. Anyone who uses our module will have to disambiguate, but this seems to be a small price to pay. Nothing can break, as Julia itself does not use Nemo.

It seems like you require users to fully qualify function calls? E.g. `Nemo.exp` etc. So with this in mind there is 0 use in also exporting the conflicting names. The only extra “gain” if you export is that you break code for people that use `exp` from Base.

> [@wbhart](#):
>
> Serious question: I actually don’t understand why people would want us to NOT export our functions. Doesn’t it ordinarily make the package really difficult and annoying to use if you don’t export the functions?

See above. The point is that `using Nemo` shouldn’t affect how you have to use other libraries (in this case `Base`).

[Next page](https://discourse.julialang.org/t/clarification-on-type-piracy/5926.md?page=2)