>> 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
and this https://www.youtube.com/watch?v=osdeT-tWjzk > 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 >>>> >>>
