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/
next prev parent 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