From: "François Bobot" <bobot@lri.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Wish: mutable variant types, equivalence with records
Date: Thu, 29 Mar 2012 17:46:31 -0500 [thread overview]
Message-ID: <4F74E647.1040603@lri.fr> (raw)
In-Reply-To: <wfk429dej5.fsf@gmail.com>
On 24/03/2012 13:45, Wojciech Meyer wrote:
> Please see [1], Alain Frisch has been working recently on implementing
> in-line records for constructor arguments.
>
> It's more implementation/design implications than people might think.
>
> [1] http://caml.inria.fr/mantis/view.php?id=5528
In the thread of this proposed feature, there is a remark that inlined
record and normal record can become competing features. There is also
the burden that inlined record as proposed can be modified only in
pattern matching.
But can't we consider that, for a semantic, syntax and typing perspective:
type t =
| A of string
| B of ({msg: string; mutable foo:int} as t2)
| C
is exactly the same thing than:
type t =
| A of string
| B of t2
| C
and t2 = {msg: string; mutable foo:int}
The only difference is that when you create a record of type t2 the tag
is directly the one of B in the first case and is the default tag for
record (the first tag if I remember well) in the second case. So in the
first case applying the constructor B is just the identity.
So you could modify the record of type t2 independently:
val f : t2 -> t2
...
match x with
| A s -> ...
| B ({ msg = ""} as r) -> B (f t2)
| C
...
The only disadvantage, I see, compared to Alain Frisch's proposition is
that two records share with difficulty the same field name. But special
case can be made when we know the record type thanks to the constructor
eg B {x=...}, C {x=...}.
PS: It's in fact not the same thing for typing in regard of module
subtyping, if t is made abstract, t2 must be made private. But that can
be quite useful.
--
François
next prev parent reply other threads:[~2012-03-29 22:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-24 18:26 Goswin von Brederlow
2012-03-24 18:32 ` Lukasz Stafiniak
2012-03-24 18:39 ` Lukasz Stafiniak
2012-03-24 18:42 ` Lukasz Stafiniak
2012-03-25 22:45 ` Goswin von Brederlow
2012-03-24 18:42 ` Jonathan Protzenko
2012-03-24 18:45 ` Wojciech Meyer
2012-03-24 18:59 ` Lukasz Stafiniak
2012-03-29 22:46 ` François Bobot [this message]
2012-03-30 12:16 ` Goswin von Brederlow
2012-03-30 15:00 ` François Bobot
2012-03-31 15:52 ` Goswin von Brederlow
2012-03-31 19:17 ` Alain Frisch
2012-03-26 8:41 ` Romain Bardou
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=4F74E647.1040603@lri.fr \
--to=bobot@lri.fr \
--cc=caml-list@inria.fr \
/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