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.