caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <alain@frisch.fr>
To: "François Bobot" <bobot@lri.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Wish: mutable variant types, equivalence with records
Date: Sat, 31 Mar 2012 21:17:24 +0200	[thread overview]
Message-ID: <4F775844.5000006@frisch.fr> (raw)
In-Reply-To: <4F74E647.1040603@lri.fr>

On 3/30/2012 12:46 AM, François Bobot wrote:
> 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.

It is an interesting idea to give an explicit type to the record 
argument, allowing it to be manipulated as a first-class value.

Instead of requiring an explicit name, one could introduce a syntax to 
refer to the implicit record declaration for a record constructor.  For 
instance, after defining:

  type t =
    | A of string
    | B of {msg:string; mutable foo:int}
    | C

one could refer to the type t/B, which would behave like a normal record 
type (with a runtime representation such that applying B is the identity).

> 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=...}.

We should rather look for a general solution to record field 
overloading.  I think that changes introduced for GADTs in the typing of 
patterns makes it quite easy to use propagated type information to 
disambiguate between record types sharing the same field names (and 
similarly for sum types sharing the same constructor names).



Alain

  parent reply	other threads:[~2012-03-31 19:17 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
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 [this message]
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=4F775844.5000006@frisch.fr \
    --to=alain@frisch.fr \
    --cc=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;
as well as URLs for NNTP newsgroup(s).