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: Christophe Raffalli <Christophe.Raffalli@u...>
Subject: Re: A proposal for overloading ...
Didier Remy a écrit :
> 
> 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.

My proposal would not solve this problem automatically but at least it
will give overloading of arithmetical operator (if you still keep
separate constants) and a few others. It is clear that if you want
something more general,
you need an algotihm that implements some kind of bactracking or that
infer all the possible types and altough it is possible, it seems much
more complex ...

> 
> 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.

But this is that actual semantics of most functionnal language !

> Cheers,
> 
>     Didier

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI