> > Can anyone point me in the right direction of the files/functions in the > core library where dispatch is handled? I'd like to explore a little so I > can make comments that account for the relative ease at implementing some > of the changes suggested. >
Start here: https://github.com/JuliaLang/julia/blob/cd455af0e26370a8899c1d7b3d194aacd8c87e9e/src/gf.c#L1655 On Thu, Apr 30, 2015 at 1:11 PM, Tom Breloff <[email protected]> wrote: > Can anyone point me in the right direction of the files/functions in the > core library where dispatch is handled? I'd like to explore a little so I > can make comments that account for the relative ease at implementing some > of the changes suggested. > > I agree that it would be really nice, in some cases, to auto-merge > function definitions between namespaces (database connects are very simple > OO example). However, if 2 different modules define foo(x::Float64, > y::Int), then there should be an error if they're both exported (or if not > an error, then at least force qualified access??) Now in my mind, the > tricky part comes when a package writer defines: > > module MyModule > export foo > type MyType end > foo(x::MyType) = ... > foo(x) = ... > end > > > ... and then writes other parts of the package depending on foo(5) to do > something very specific. This may work perfectly until the user calls > "using SomeOtherModule" which in turn exported foo(x::Int). If there's an > auto-merge between the modules, then foo(x::MyModule.MyType), foo(x::Any), > and foo(Int) all exist and are valid calls. > > *If* the auto-merge changes the calling behavior for foo *within module > MyModule*, then we have a big problem. I.e. we have something like: > > internalmethod() = foo(5) > > > that is defined within MyModule... If internalmethod() now maps to > SomeOtherModule.foo(x::Int)... all the related internal code within > MyModule will likely break. However, if internalmethod() still maps to > MyModule.foo(), then I think we're safe. > > > So I guess the question: can we auto-merge the foo methods *in user space > only *(i.e. in the REPL where someone called "using MyModule, > SomeOtherModule"), and keep calls within modules un-merged (unless of > course you call "using SomeOtherPackage" within MyModule... after which > it's my responsibility to know about and call the correct foo). > > Are there other pitfalls to auto-merging in user-space-only? I can't > comment on how hard this is to implement, but I don't foresee how it breaks > dispatch or any of the other powerful concepts. > > > > On Thursday, April 30, 2015 at 12:19:07 PM UTC-4, Michael Francis wrote: >> >> My goal is not to remove namespaces, quite the opposite, for types a >> namespace is an elegant solution to resolving the ambiguity between >> different types of the same name. What I do object to is that functions >> (which are defined against user defined types) are relegated to being >> second class citizens in the Julia world unless you are developing in Base. >> For people in Base the world is great, it all just works. For everybody >> else you either shoe horn your behavior into one of the Base methods by >> extending it, or you are forced into qualifying names when you don't need >> to. >> >> 1) Didn't that horse already bolt with Base. If Base were subdivided into >> strict namespaces of functionality then I see this argument, but that isn't >> the case and everybody would be complaining that they need to type >> strings.find("string") >> 2) To me that is what multiple dispatch is all about. I am calling a >> function and I want the run time to decide which implementation to use, if >> I wanted to have to qualify all calls to a method I'd be far better off in >> an OO language. >> >> >> On Thursday, April 30, 2015 at 2:15:51 AM UTC-4, Tamas Papp wrote: >>> >>> >>> On Thu, Apr 30 2015, Stefan Karpinski <[email protected]> wrote: >>> >>> > Function merging has these problems: >>> > >>> > 1. It complects name resolution with dispatch – they are no longer >>> > orthogonal. >>> > 2. It makes all bindings from `using` semantically ambiguous – you >>> have >>> > no idea what a name means without actually doing a call. >>> >>> IMO orthogonality of name resolution and dispatch should be preserved -- >>> it is a nice property of the language and makes reasoning about code >>> much easier. Many languages have this property, and it has stood the >>> test of time, also in combination with multiple dispatch (Common >>> Lisp). Giving it up would be a huge price to pay for some DWIM feature. >>> >>> Best, >>> >>> Tamas >>> >>
