Version française
Home     About     Download     Resources     Contact us    
Browse thread
status of some big "important" features?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Didier Remy <Didier.Remy@i...>
Subject: Re: A proposal for overloading ...
Christophe,

I am afraid that the picture might be far more complicated that what your
description suggests. Of course, two identifiers might have ambiguous
types when considered alone, but become unambiguous when combined together
in a program (this is at the basis of overloading, when the context should
be used to desambiguate). For instance,

        foo: int -> int or string -> string
        bar: string or bool

Then, (for, bar) is ambiguous but (foo bar) is not.  

However, to solve the latter case seems to imply something more complicated
than your simple schema. 

The above example is just a basic example of overloading.  There are many
variations involving ambiguous (maybe polymorphic) local bindings that are
used non-ambiguously for which it is not clearly whether their should be
ambiguity should be resolved or propagated.

In summary you cannot save the effort of a careful formal specification of
what is an overloaded symbol, how overloading is propagated, and how it is
resolved.

> Then, if there is still some identifiers with ambiguous value, we choose
> one (the first by position in the source code ?), and assign it the
> first possible value in the list (this choice insure compatibility with
> existing code). 

Both notions (first position in the code, first possible value in the list)
seems completely meaningless to me. 

Cheers,

    Didier