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 SAA19903 for caml-redistribution; Mon, 22 Feb 1999 18:56:52 +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 SAA23929 for ; Mon, 22 Feb 1999 18:56:25 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id SAA23313; Mon, 22 Feb 1999 18:56:21 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA09662; Mon, 22 Feb 1999 18:56:21 +0100 (MET) From: Pierre Weis Message-Id: <199902221756.SAA09662@pauillac.inria.fr> Subject: Re: anonymous record types in variants To: maf@microsoft.com (Manuel Fahndrich) Date: Mon, 22 Feb 1999 18:56:21 +0100 (MET) Cc: caml-list@inria.fr In-Reply-To: <25983782061AD111B0800000F86310FE1026CB26@RED-MSG-42> from "Manuel Fahndrich" at Feb 22, 99 08:37:35 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis > I don't agree with Anton. The reason I want variants with anonymous record > arguments is to name the fields explicitly. I don't want to incur a runtime > cost of an extra indirection. The compilation of named fields vs. tuples > would be the same. That's why a construction like > > > match x with A r -> ... r.x ... r.y ... > > would not be desirable, since it requires the record r to be stored as a > separate block from the A r value. If you restrict record access for these > anonymous records as Xavier pointed out > > > match x with A{lbl1 = x; lbl2 = y} -> ... > > > then you can implement them as efficiently as a variant with a tuple > argument. > > -Manuel An even better scheme would be to allow access to the fields with the dot notation, considering that a value of type type t = A of {labl1 : int; labl2 : bool} is in fact a tuple with named field tagged with A (the treatment is completely similar to constructors with tuple arguments, and as the value A (..., ...) cannot be pattern matched to extract the tuple, then A {...} could not be pattern matched to extract the record). Then match expr with A {lbl1 = _; lbl2 = _} as x -> x.lbl1 ... x.lbl2 is conceivable (easy to compile, not too difficult to type check). Moreover, this could be easily extended to mutable labels, using the usual syntax: if t is defined as type t = A of {mutable labl1 : int; mutable labl2 : bool} we could write match expr with A {lbl1 = _; lbl2 = _} as x -> x.lbl1 <- x.lbl1 + 1 ... x.lbl2 <- not x.lbl2 I think this is not too difficult to understand (given the simliarity with the actual semantics of constructors in Objective Caml) and not too difficult to implement. Last but not least, it does not require any extra syntax! Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/