Bookmarked and watching. Thanks :)
On Thursday, April 30, 2015 at 1:39:54 PM UTC-4, Mauro 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. > >> > > > > 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] > <javascript:>> 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 > >>>> > >>> > >
