On Friday, May 15, 2015 at 9:36:01 PM UTC-4, ele...@gmail.com wrote:
>
>
>
> On Saturday, May 16, 2015 at 6:58:18 AM UTC+10, Scott Jones wrote:
>>
>> About functions that actually take the same types (which means they are
>> operating on types they they didn't define themselves), I think the new
>> approach in 0.4 (give a warning and don't merge in the "new" meaning) is
>> correct.
>> I would not like to see that change to have the ambiguity only resolved /
>> warned about at run-time.
>>
>> I've said all along, I'm only talking about cases where there is no
>> ambiguity...
>> Package A defines TypeA, and all of it's exported functions always have
>> TypeA in their method signature (even if it's only `::Type{TypeA})`. Say
>> it has a "connect(db::TypeA, ipaddr, port)" method...
>> Package B defines TypeB, (same as above), Why should it not be able to
>> also define a "connect(db::TypeB,datasetname:UTF8String)"?
>>
>
> Hi Scott,
>
> I'm not sure you meant it, but the way you wrote that makes it sound like
> a simple fairly local test:
>
> if module defines *concrete* type and all methods have a parameter of that
> type: merge ok
>
> But as I understand it, the test would need to be more complex, for
> function 'f' something like:
>
> for each function named f in the current scope:
> for each method of the function:
> for each parameter position in the method:
>
Not so, you stop at the first type that is defined in the same module.
> if parameter is varargs: can't merge # not sure how else to
> handle varargs, can fill infinite parameter positions
> get the type of the parameter
>
If the varargs is limited to a type, or union of types, you simply check
that (for unions, *all* the types in the union have to be defined in the
same module for it to count)
> if the type depends on a generic parameter: can't merge # since
> the types the generic parameter takes depends on the uses, and we don't
> know that until we know if it merges or not
>
Give an example please of exactly what you mean here... (remember, I'm
still a Julia newbie...)
> if the type of the parameter is a subtype of a type already
> used in this parameter position in a different function: can't merge #
> "ambiguous"
>
Again, not sure what the problem is... that sort of ambiguity check you'd
have anyway, right?
> add the type to the list for this parameter position
> whew, ok to merge
>
> Since Julia is a dynamic JITed language not an AOT language I think this
> can be run at any time the JIT compiles some new code. That could do
> terrible things to performance.
>
I really don't think so...
I also think that when declaring/defining a method in a module, you should
be able to specify the following:
1) If it is meant to extend a function outside the module (and possibly
specify exactly which function, i.e.something like module.name)
2) If it is meant to be possibly the root of a new concept that might be
extended by other packages, and the programmer guarantees that it is meant
to be unambiguous (the compiler would check to
see if it used at least one local type, but it would only need to do
that in this case)
3) If it is meant to be only callable via module.name (or
module.module.name [etc]), outside the module, i.e. it is not allowed to
make it extend something at the higher level.
4) If it can be brought into a higher level, but is not guaranteed to be
unambiguous.. this would get the same checking that all methods get now,
and would not be merged into a higher level if the name conflicted
(that is the same behavior in v0.4)
5) If it is only meant to be callable *within* the module...
Julia really lacks the capability (AFAIK) to isolate code (and types /
enums / etc) in a module, and that causes a lot of headaches.
