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 <ste...@karpinski.org> 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
>>
>
