From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: Enrico Tassi <enrico.tassi@inria.fr>
Cc: Mailing List OCaml <caml-list@inria.fr>
Subject: Re: [Caml-list] How to rename a record field
Date: Thu, 6 Sep 2018 22:17:25 +0900 [thread overview]
Message-ID: <5972F2FD-82AA-4C68-BE0A-D913A2D08658@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <20180906130314.ymqnpcxbrz5d7tj4@gargamel>
On 2018/09/06 22:03, Enrico Tassi wrote:
>
> On Thu, Sep 06, 2018 at 01:48:23PM +0200, Gabriel Scherer wrote:
>> MPR#7102: Ability to re-export a variant definition with renamed
>> constructors?
>> https://caml.inria.fr/mantis/view.php?id=7102
>
> Thanks for the pointer, but I'm not sure I understand how the arguments
> made there apply to records.
Records being the dual of variants, all the arguments apply.
Namely, if the name is allowed to change, field access can no longer
be seen as the intuitive projection (by name rather than position, since
only name information is available in the source code).
Field name disambiguation works in the same way too.
There is also the same problem with GADTs assuming that two
record types with different field names are distictinct.
The fact the representation is identical is just an implementation detail.
Tuples too share the same representation.
Jacques Garrigue
> My intuition is that, given that records are compared by name, there
> should be no difference between adding the equation t = old or
> casting (with Obj.magic) each and every term of type old to type t.
> To my knowledge the two records have the very same representation at run
> time, that does not depend on the names of the fields but just their
> types.
>
> I've even tried to disable the check in typing/includecore.ml around
> line 230 and the following silly test seems to work.
>
> type old = { bad : int; stuff : bool }
> type t = old = { good : int; stuff : bool }
>
> let rb = { bad = 3; stuff = false }
> let rg = { good = 3; stuff = false }
>
> let _ = Printf.printf "%b\n" rb.stuff
> let _ = Printf.printf "%b\n" rg.stuff
> let _ = Printf.printf "%d\n" rb.bad
> let _ = Printf.printf "%d\n" rg.good
> let _ = Printf.printf "%d\n" rg.bad
> let _ = Printf.printf "%d\n" rb.good
> let _ = Printf.printf "%d\n" { rb with good = rb.bad + 1 }.bad
> let _ = Printf.printf "%b\n" { rb with stuff = not rg.stuff }.stuff
>
> Where is my intuition wrong?
>
> Why records needs to be compared by name and not by (type) structure?
> Sorry if the question is silly, but I really don't know.
>
> Best,
--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
next prev parent reply other threads:[~2018-09-06 13:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 11:36 Enrico Tassi
2018-09-06 11:48 ` Gabriel Scherer
2018-09-06 13:03 ` Enrico Tassi
2018-09-06 13:17 ` Jacques Garrigue [this message]
2018-09-06 14:18 ` Enrico Tassi
2018-09-06 23:34 ` Jacques Garrigue
2018-09-06 16:20 ` Alain Frisch
2018-09-06 16:21 ` Alain Frisch
2018-09-06 23:45 ` Jacques Garrigue
2018-09-07 8:36 ` Alain Frisch
2018-09-07 10:13 ` Jacques Garrigue
2018-09-07 12:49 ` Alain Frisch
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=5972F2FD-82AA-4C68-BE0A-D913A2D08658@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=enrico.tassi@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).