[Caml-list] open extensible types representation

[Caml-list] open extensible types representation

[Milan Stanojević]

4.02 will have extensible data types.

What is the runtime representation of an extensible data type?

Thanks!

Re: [Caml-list] open extensible types representation

[Jeremie Dimino]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

For a constructor argument it is a constructed value of size 2 and tag
[Obj.object_tag]:
- the first field of this value is a string, it is the name of the
constructor
- the second field is a unique integer identifier

For a constructor with [n] arguments, it is of value of size [n+1]. The
first field points to the same 2-fields constructed value described above
and the other fields are the arguments.

The reason the tag of the constructor "bucket" is [Obj.object_tag] is so
that the generic [Pervasives.compare] compares only the integer identifiers
in the second fields.


On Tue, May 13, 2014 at 4:53 PM, Milan Stanojević <milanst@gmail.com> wrote:

> 4.02 will have extensible data types.
>
> What is the runtime representation of an extensible data type?
>
> Thanks!
>
> --
> 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
>



-- 
Jeremie

[-- Attachment #2: Type: text/html, Size: 1753 bytes --]

Re: [Caml-list] open extensible types representation

[Jeremie Dimino]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

On Tue, May 13, 2014 at 5:07 PM, Jeremie Dimino <jdimino@janestreet.com>wrote:

> For a constructor argument it is a constructed value of size 2 and tag
> [Obj.object_tag]:
>

I meant constructor  *without* argument

-- 
Jeremie

[-- Attachment #2: Type: text/html, Size: 582 bytes --]

Re: [Caml-list] open extensible types representation

[Milan Stanojević]

Thanks, Jeremie.

How are these unique identifiers created?
Is matching done by doing binary search on them?



On Tue, May 13, 2014 at 12:08 PM, Jeremie Dimino <jdimino@janestreet.com> wrote:
> On Tue, May 13, 2014 at 5:07 PM, Jeremie Dimino <jdimino@janestreet.com>
> wrote:
>>
>> For a constructor argument it is a constructed value of size 2 and tag
>> [Obj.object_tag]:
>
>
> I meant constructor  *without* argument
>
> --
> Jeremie

Re: [Caml-list] open extensible types representation

[Jeremie Dimino]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Tue, May 13, 2014 at 5:39 PM, Milan Stanojević <milanst@gmail.com> wrote:

> How are these unique identifiers created?
>

They are created at runtime by incrementing a global counter, using the
same function as for objects.


> Is matching done by doing binary search on them?


No, the ordering is not known at compile time.

-- 
Jeremie

[-- Attachment #2: Type: text/html, Size: 826 bytes --]

Re: [Caml-list] open extensible types representation

[Milan Stanojević]

On Tue, May 13, 2014 at 12:57 PM, Jeremie Dimino <jdimino@janestreet.com> wrote:
> On Tue, May 13, 2014 at 5:39 PM, Milan Stanojević <milanst@gmail.com> wrote:
>>
>> How are these unique identifiers created?
>
>
> They are created at runtime by incrementing a global counter, using the same
> function as for objects.
>
>>
>> Is matching done by doing binary search on them?
>
>
> No, the ordering is not known at compile time.

So matching is a linear search?

Re: [Caml-list] open extensible types representation

[Alain Frisch]

On 05/14/2014 08:11 PM, Milan Stanojević wrote:
> So matching is a linear search?

Yes.

One could think about improving that, for instance by matching first on 
the constructor name (relying on the new much-improved compilation for 
pattern matching on strings).  But this doesn't work in presence of 
constructor rebinding (which can change the name).  Maybe it's one of 
those cases where a JIT compiler can have a clear advantage over a 
static one.

-- Alain

Re: [Caml-list] open extensible types representation

[Milan Stanojević]

On Wed, May 14, 2014 at 2:42 PM, Alain Frisch <alain.frisch@lexifi.com> wrote:
> On 05/14/2014 08:41 PM, Alain Frisch wrote:
>>
>> One could think about improving that, for instance by matching first on
>> the constructor name (relying on the new much-improved compilation for
>> pattern matching on strings).  But this doesn't work in presence of
>> constructor rebinding (which can change the name).
>
>
> Well, of course, one could always use this technique as a fast path and use
> linear search as fall back.  It's not clear that the gain justifies the
> extra effort.

And linear search is likely faster for a small number of variants.

The rebinding of constructors is interesting. What are uses case apart
from reducing verbosity in some cases?

Re: [Caml-list] open extensible types representation

[Leo White]

> The rebinding of constructors is interesting. What are uses case apart
> from reducing verbosity in some cases?

Naming a constructor created by a functor.

For example, the following excerpts from my own toy example
(testsuite/tests/typing-extensions/msg.ml in the ocaml sources):

    module Msg : sig

      type 'a tag

      (* ... *)

      module Define (D : Desc) : sig
        type 'a tag += C : D.t tag
      end

    end = struct

      type 'a tag = ..

      (* ... *)

    end

    (* ... *)

    module StrM = Msg.Define(struct
      type t = string
      (* ... *)
    end);;

    type 'a Msg.tag += String = StrM.C;;

Note that the `Msg.tag` type has been made abstract, so the `Define`
functor is the only method of creating new constructors.

The rebinding gives the `String` constructor a meaningful name, and
allows you to expose it in your interface rather than expose all of
`StrM`.

Regards,

Leo

Re: [Caml-list] open extensible types representation

[Frédéric Bour]

Hi,

You might be interested in the following text:

     http://yawdp.com/~def/exn_en.txt

It's a draft about the encoding of exceptions, but open-types are also 
covered at the end.

(Beware, it has not been reviewed, use at your own risk :))

On 05/13/2014 04:53 PM, Milan Stanojević wrote:
> 4.02 will have extensible data types.
>
> What is the runtime representation of an extensible data type?
>
> Thanks!
>

Re: [Caml-list] open extensible types representation

[Frédéric Bour]

I updated the document to take into account a change in the 
representation of exception values without parameters.

On 05/13/2014 05:37 PM, Frédéric Bour wrote:
> Hi,
>
> You might be interested in the following text:
>
>     http://yawdp.com/~def/exn_en.txt
>
> It's a draft about the encoding of exceptions, but open-types are also 
> covered at the end.
>
> (Beware, it has not been reviewed, use at your own risk :))
>
> On 05/13/2014 04:53 PM, Milan Stanojević wrote:
>> 4.02 will have extensible data types.
>>
>> What is the runtime representation of an extensible data type?
>>
>> Thanks!
>>
>
>