@Scott, @Toivo In my mind this changing the meaning of existing code is happening all the time with the verbs in Base. Each time I use a module it can (and likely does) inject new behavior for verbs defined in Base ( or for verbs defined in any other module) These silently change the way other modules work. This is actually the beauty of the type system as it allows a module to add features to another module without having to fork the module. The only thing you can't do is add new verbs to an existing module.
Is that not the case ? On Friday, May 15, 2015 at 8:08:51 PM UTC+10, Scott Jones wrote: > > > > On Thursday, May 14, 2015 at 3:13:09 PM UTC-4, Toivo Henningsson wrote: >> >> I don't think it should be allowed. What if two packages try to add >> functions with the same name to Base that do completely different things? >> And what if they are both applicable to some of the same argument types? >> > > As long as there is no ambiguity in the types, why should they not be able > to? > That is *way* too restrictive... > Because if some module adds an ambiguous type it will silently change the meaning of existing code. > > >> Beyond that, I think being able to add definitions to a module from the >> outside comes with an extra set of problems. What if you define a function >> that shadows a function that it was using from another module? What if >> there was a big where someone was trying to access a function from another >> module that wasn't there, but is was named because the function had been >> introduced from the outside? > >
