From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: weis
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA09011 for caml-redistribution; Wed, 19 Jan 2000 22:19:01 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA11241 for <caml-list@pauillac.inria.fr>; Wed, 19 Jan 2000 22:18:00 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA20290;
	Wed, 19 Jan 2000 22:17:59 +0100 (MET)
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA30842; Wed, 19 Jan 2000 22:17:58 +0100 (MET)
From: Pierre Weis <Pierre.Weis@inria.fr>
Message-Id: <200001192117.WAA30842@pauillac.inria.fr>
Subject: Re: Compiler translation of array indexing
To: mottl@miss.wu-wien.ac.at (Markus Mottl)
Date: Wed, 19 Jan 2000 22:17:58 +0100 (MET)
Cc: caml-list@inria.fr
In-Reply-To: <200001191708.SAA15007@miss.wu-wien.ac.at> from "Markus Mottl" at Jan 19, 0 06:08:31 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis

> 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/