> The article says that the name of types and constructors is dropped for the
> conversion to the interchange format. But what about types like:
>
> type t = Foo | Bar
>
> How are such cases treated? Another program might define this as
>
> type t = Bar | Foo
>
> and possibly means the same thing with the same constructors, however, the
> internal representation might be completely different (maybe due to order
> of constructors).
1) Internal representations are indeed absolutely similar and
compatible, and this is carefully stated as a fundamental hypothesis
about the value representation algorithm of the compiler, in order to
prove the safety of our value I/O mechanism.
2) One can imagine that the Caml compiler sorts the names of
constructors (and labels) when a type is defined, to have a more
canonical representation of the values of data types.
3) Anyway, wih the current Caml compilers, since the representations
of Foo and Bar are indeed valid values of each of your t type, they
can safely be read as a value of the other type.
4) If you want to ensure a strong semantic property on the data you
are exchanging, you must use an abstract data type: in this
case a unique footprint is carried along with the values that are
exchanged, and this footprint can ensure some invariant properties of
those values.
> Are there primitives for disambiguating such cases? E.g. my program reads
> in data from another program, I see that it gets the constructors the wrong
> way round so I just use some primitive to get it right again?
This is not implemented. I don't know if this can really be done
polymorphically. This is further research :)
Pierre Weis
INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/
This archive was generated by hypermail 2b29 : Wed Jan 19 2000 - 22:22:18 MET