caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <alain.frisch@lexifi.com>
To: David Allsopp <dra-news@metastack.com>,
	Dmitry Bely <dmitry.bely@gmail.com>,
	Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] GADT memory representation
Date: Thu, 1 Dec 2016 12:51:25 +0100	[thread overview]
Message-ID: <3f89d13a-14f0-090b-be96-d3f67fcb95f3@lexifi.com> (raw)
In-Reply-To: <E51C5B015DBD1348A1D85763337FB6D90135555A23@Remus.metastack.local>

On 01/12/2016 10:52, David Allsopp wrote:
> Dmitry Bely wrote:
>> I need to access/modify GADT data from C glue code. What is their memory
>> representation? Is there any difference from ordinary sum types?
>
> It's the same - GADTs are "just" add a lot of clever typing stuff on top of a normal sum type - they don't affect the runtime operation of the code.
>
>> Unfortunately OCaml manual doesn't even mention GADTs in section
>> "Interfacing C with OCaml".
>
> That's worth a GPR/Mantis issue.

I'm not sure we want to document the memory layout of GADTs.  I don't 
think there are concrete plans to do so, but it might be considered to 
change the representation of GADTs so that they cannot be used to 
compare values of different types with the polymorphic comparison 
function.  Today you can write:

   type t = E: 'a -> t

   let () = assert(E 1 = E true)

A similar "bad" behavior used to be available for exceptions and this 
was "fixed" by changing their representation (their "slot" now has 
object_tag and a (per process) unique id).  We might want to do the same 
for GADTs (not an easy decision since it would add a lot of overhead) 
and for first-class modules as well.


Alain

  parent reply	other threads:[~2016-12-01 11:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01  9:22 Dmitry Bely
2016-12-01  9:52 ` David Allsopp
2016-12-01 10:26   ` Dmitry Bely
2016-12-01 11:51   ` Alain Frisch [this message]
2016-12-01 14:12     ` octachron
2016-12-01 14:32     ` Dmitry Bely
2016-12-01 14:50       ` Gabriel Scherer
2016-12-01 15:21     ` Josh Berdine
2016-12-03 14:50     ` David Allsopp

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=3f89d13a-14f0-090b-be96-d3f67fcb95f3@lexifi.com \
    --to=alain.frisch@lexifi.com \
    --cc=caml-list@inria.fr \
    --cc=dmitry.bely@gmail.com \
    --cc=dra-news@metastack.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;
as well as URLs for NNTP newsgroup(s).