caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Christophe Raffalli <Christophe.Raffalli@univ-savoie.fr>
To: Didier.Remy@inria.fr, caml-list@inria.fr
Subject: Re: A proposal for overloading ...
Date: Tue, 02 Jan 2001 14:08:43 -0500	[thread overview]
Message-ID: <3A52273B.E55BE243@univ-savoie.fr> (raw)
In-Reply-To: <20010102113830.A8127@morgon.inria.fr>

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



      reply	other threads:[~2001-01-02 17:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-26 23:47 status of some big "important" features? Chris Hecker
2000-12-28  9:10 ` Daniel de Rauglaudre
2000-12-30 19:30   ` Chris Hecker
2000-12-30 20:53     ` Daniel de Rauglaudre
2000-12-31  1:58       ` Chris Hecker
2000-12-31  3:08         ` Daniel de Rauglaudre
2001-01-02 17:39           ` William Chesters
2000-12-31 20:39   ` John Max Skaller
2000-12-28 20:19 ` A proposal for overloading Christophe Raffalli
2001-01-02 10:38   ` Didier Remy
2001-01-02 19:08     ` Christophe Raffalli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A52273B.E55BE243@univ-savoie.fr \
    --to=christophe.raffalli@univ-savoie.fr \
    --cc=Didier.Remy@inria.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).