From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA31150 for caml-red; Tue, 2 Jan 2001 18:02:47 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA27258 for ; Tue, 2 Jan 2001 11:51:11 +0100 (MET) Received: from morgon.inria.fr (morgon.inria.fr [128.93.8.33]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f02Ap7b12044; Tue, 2 Jan 2001 11:51:07 +0100 (MET) Received: (from remy@localhost) by morgon.inria.fr (8.9.3/8.9.3) id LAA08140; Tue, 2 Jan 2001 11:38:32 +0100 Date: Tue, 2 Jan 2001 11:38:32 +0100 From: Didier Remy To: Christophe Raffalli Cc: caml-list@inria.fr Subject: Re: A proposal for overloading ... Message-ID: <20010102113830.A8127@morgon.inria.fr> Reply-To: Didier.Remy@inria.fr References: <4.3.2.7.2.20001226151428.00b2f680@shell16.ba.best.com> <3A4BA041.F878C6BE@univ-savoie.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <3A4BA041.F878C6BE@univ-savoie.fr> Organization: INRIA, BP 105, F-78153 Le Chesnay Cedex Phone: (33) 1 3963 5317 -- Sec: (33) 1 3963 5570 -- Fax: (33) 1 3963 5684 Web: http://cristal.inria.fr/~remy Sender: weis@pauillac.inria.fr 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