Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Pierre Weis <Pierre.Weis@inria.fr>
To: maf@microsoft.com (Manuel Fahndrich)
Cc: caml-list@inria.fr
Subject: Re: anonymous record types in variants
Date: Mon, 22 Feb 1999 18:56:21 +0100 (MET)	[thread overview]
Message-ID: <199902221756.SAA09662@pauillac.inria.fr> (raw)
In-Reply-To: <25983782061AD111B0800000F86310FE1026CB26@RED-MSG-42> from "Manuel Fahndrich" at Feb 22, 99 08:37:35 am

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





  reply	other threads:[~1999-02-22 17:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-22 16:37 Manuel Fahndrich
1999-02-22 17:56 ` Pierre Weis [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-02-18 14:03 Don Syme
1999-02-18 10:13 Frank A. Christoph
1999-02-16 17:40 Don Syme
1999-02-15 18:03 Manuel Fahndrich
1999-02-15 10:30 Don Syme
1999-02-12 20:53 Christopher Jeris
1999-02-16 10:57 ` Anton Moscal
1999-02-17  9:32 ` Xavier Leroy
1999-02-17 18:09   ` Christopher Jeris
1999-02-17 19:14     ` Didier Remy
1999-02-22  8:44   ` Anton Moscal
1999-02-22 13:00     ` Pierre Weis

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=199902221756.SAA09662@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=maf@microsoft.com \
    /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