From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA20086; Thu, 17 Jan 2002 19:06:07 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 TAA19791 for ; Thu, 17 Jan 2002 19:06:07 +0100 (MET) Received: from morgon.inria.fr (morgon.inria.fr [128.93.8.33]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g0HI5nX16190; Thu, 17 Jan 2002 19:05:49 +0100 (MET) Received: (from remy@localhost) by morgon.inria.fr (8.11.6/8.11.6) id g0HI6Cp25217; Thu, 17 Jan 2002 19:06:12 +0100 Date: Thu, 17 Jan 2002 19:06:12 +0100 From: Didier Remy To: Alain Frisch Cc: Jeff Henrikson , caml-list@inria.fr Subject: Re: [Caml-list] record labels of record scope using camlp4 Message-ID: <20020117190611.A25214@morgon.inria.fr> Reply-To: Didier.Remy@inria.fr References: <000101c19ccc$ffe8e8c0$0b01a8c0@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from frisch@clipper.ens.fr on Mon, Jan 14, 2002 at 01:15:04PM +0100 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: owner-caml-list@pauillac.inria.fr Precedence: bulk > Another way would be to use type information provided by the type-checker. > For accessing field, here is a description of a simple patch to the > type-checker that could be handy; the idea is that, when the expression e > is known to be a record of a given type, one can use a "record scope" rule > for label. Isn't this just a form of static and local resolution of overloading? However, local resolution does not commute with unification... Hence, the specification of well-typed programs should then strongly depend on the order in which unifications (i.e. type inference) are performed. Do you have a specification of well-typed programs but the type-inference algorithm itself? > A ten-minutes hack leads me to: [...] > This patch allows to write things like: > > type t = { x : int; y : int };; > type s = { x : string };; > let f (t : t) : int = t.x;; > > The same could be done for record expression (in function type_expect): > > let r : t = { x = 2; y = 3 } in > ... > On the one hand, this kind of interaction with the type-checker is quite > dangerous as it breaks complete type inference, but in OCaml, there are > already some cases where type annotations are mandatory; on the other > hand, it leads to a lightweight syntax and is probably what programmers > expect. It is true that Ocaml differs from the nice theory of core ML in a few places. However, we have tried to keep those differences as unsignificant as possible, and as few as possible. For example, a module with a weak type variable in its principal signature is rejected, while any ground instantiation of this weak type variable would be accepted, so, yes: ``Ocaml does not have principal types''. However, type inference is still easy to specify, and in particular does not rely in which operations are performed. Didier ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr