I think I should add some further explanation here, since I’ve probably not explained the reasons for wanting to do this sufficiently well.

Currently Nemo.jl is a package which provides both generic implementations of a bunch of algebraic functionality (power series, univariate and multivariate polynomials, fraction fields, residue rings, permutation groups, etc) and wrappers for various C libraries that provide highly optimised implementations over specific rings (Flint, Arb, Antic).

However, we’ve realised that if users want to apply Nemo functions to types provided by other packages, they need to build Nemo and all its C dependencies just to apply our generic Julia functionality over their types. This is inconvenient for them, and makes Nemo.jl far less useful than it ought to be.

Our idea is to separate Nemo into two components, one with all the generic functionality, written entirely in Julia, the other with all the wrappers of C libraries. We’ve actually been explicitly asked to do this by potential users. And we’ve been working towards this for some time. Most of the recent commits to Nemo.jl have been to allow this to happen in the near future.

But now we have to consider how the generic package can be tested. We can no longer write functions that test the generic Nemo power series, for example, over integer types provided by Flint! The package also isn’t useful as a standalone package, unless it can be used with types provided by Julia. This implies that we must be able to construct Nemo power series over Julia Integer and Rational types. If we don’t permit this, we make the package both useless as a standalone package, and we make it impossible to test the package properly. And our experience is that complex code that isn’t tested is broken.

Now, it is possible to just define power series over Julia Integer and Rational types separately. But now there is no way to soundly test the generic code. Of course it’s possible to construct more complicated rings to test the generic code over. But this has a far lower probability of finding bugs. This is essentially what we have been doing up until recently, and when we switched over to allowing Julia Integers and Rationals, we found about a dozen bugs in our generic polynomial module alone. This underscores the importance of testing the generic code over Julia Integer and Rational types and not writing special functions to handle this case.

Since our users won’t allow us to change the names of functions like exp, sin, inv, sqrt, etc., there really is only one possible solution that I see.

I should note that there are computer algebra systems that define exp, sin, sqrt, etc. on integer and rational types as Julia does, and there are those that don’t. But real computer algebra systems have the advantage that library code is not written in the same language as user code. That is also an option for Nemo, but then Nemo ceases to be a useful Julia module.

In symbolic systems, exp(2) returns the symbolic expression exp(2). In some systems like Python, you have to explicitly import math to get exp or sqrt defined. In most computer algebra systems 1/2 returns the exact rational value 1/2.

There’s no really easy solution here. Regardless of which solution we choose, we lose something. We can’t please everyone.

Anyway, our original question has been answered. What we want to do is not considered type piracy. The decision on what solution we choose is still pending. But so far, the best solution seems to be the one I’m proposing. And I’m pleased to find that it is permitted and won’t stop us tagging releases.