Re: [Caml-list] segfault in simple program with 4.02 native

[Martin Jambon <martin.jambon@ens-lyon.org>]

On Sun 07 Sep 2014 06:28:34 PM PDT, Martin Jambon wrote:
> On Sun 07 Sep 2014 11:47:43 AM PDT, Alain Frisch wrote:
>> On 9/6/2014 7:51 AM, Martin Jambon wrote:
>>> Thanks for the explanation, Jeremy. I guess atdgen will have to use
>>> "option refs" after all unless someone has a better idea.
>>
>> I might be missing some context, but the current code seems to playing
>> two different tricks with the type system:  using (Obj.magic 0.) as a
>> dummy initial default value (to avoid references) and mutating
>> normally immutable fields with Obj.set_field.  Is that right?
>
> Yes, exactly.
>
>>  You
>> might be able to keep the first trick, but storing the values in local
>> references instead of field of the the target record (if those
>> references don't espace from the function, they will be represented as
>> local mutable variables, whose mutation might actually be more
>> efficient than those of the record fields),  building the target
>> record at the end by reading from those references.
>
> Christophe Troestler also suggested this solution in a private reply.
> I was afraid of the cost of the refs, so it's great to know that
> they're optimized away.

I think we now have a working implementation for json readers in atdgen 
(https://github.com/mjambon/atdgen/tree/fix-magic-ocaml402).

However, atdgen also supports a binary format called biniou (Intro: 
http://mjambon.com/biniou.html Spec: 
https://github.com/mjambon/biniou/blob/master/biniou-format.txt). It is 
broken for the same reason as the JSON readers, but it is trickier to 
fix. Biniou allows sharing records and cyclic data. So far readers have 
been working by first creating a record with uninitialized fields, and 
then by proceeding with reading the field values. If a reference to the 
record is found, we just use the record that we already created, even 
if some of its fields are still unset.

The problem here is that we need to create the record before reading 
its fields. Perhaps we could use the solution proposed by Milan 
Stanojević earlier in this thread, consisting in creating a private 
record type with mutable fields and at the end convert it to the normal 
type using Obj.magic.

... Or we could just drop support for some features, hence the 
following questions:

1. Does anyone use biniou at all?
2. Does anyone use biniou with cyclic data?