By the way, here are some potential things that could solve this for us:

1) Allow individual methods to be callable, as in Julia 0.4 (so long as we 
can look the methods up at "compile time" in a module and assign them to a 
const in the module so that they can be called). As far as we can see, this 
has been removed in Julia 0.5.

2) Have a syntax for calling a method with a given signature, e.g. 
apply(det, (MatElem,), m) or something like that. Something like this used 
to exist in Julia but has been removed.

3) Have Julia not print an ambiguity warning about 
Base.det/Nemo.det/Hecke.det when calling det on a matrix where there is a 
specific implementation for that type in Hecke, but only something more 
general in the other modules. Currently Julia complains that you might mean 
Base.det or Hecke.det even though the former does not implement a function 
for matrices of type SpecialMat. But why? What's ambiguous here?

4) Remove the requirement for a module to extend the definition from Base 
or whatever other packages it uses, if it is only defining the function for 
one of its own types and not a type that is present in Base or that other 
module.

5) Introduce a way of calling an implementation provided by a specific 
module, e.g. specifying Nemo.det would only call the version actually 
defined in Nemo. This might feel like the current behaviour, but it doesn't 
actually work, since it is Base.det or Nemo.det that Hecke needs to be 
overloaded in the first place. So calling Nemo.det from within Hecke.det 
just causes it to call Hecke.det for that specific type, causing a stack 
overflow. 

6) Allow us to define function Hecke.det (and still export it as det) in 
Hecke, and call Nemo.det from within that implementation. Again, this might 
feel like the current behaviour, but it doesn't work because it is Nemo.det 
or Base.det that needs to be defined in Hecke, currently.

Bill.

Reply via email to