Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
RE: [Caml-list] Caml 3.01 : pb with include
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-03-21 (13:26)
From: Dave Berry <Dave@k...>
Subject: RE: [Caml-list] Caml 3.01 : pb with include
I can add a little background to Xavier's remark about SML'97.  One of
the main changes in SML'97 from SML'90 was the removal of the
"stamp-based" notion of structure sharing (where two structures were
shared only if they were exactly the same structure).  In an early draft
this change went so far as to remove the structure sharing syntax

After some discussion, the syntax was retained, and interpreted purely
as a shorthand for sharing all the (flexible) types in the structures.
This was partly for backwards compatibility, which is why the SML'97
standard didn't add a "where structure" form analogous to "where type".
(SML/NJ allows this as an extension to the language, and I think other
implementations may have picked this up).

I find the structure sharing syntax genuinely useful.  As an example, if
you have a module containing all the (recursive) datatypes of an
abstract syntax, and you use this file in many other modules, it's
useful to specify that the types are shared using a single line instead
of having to add a sharing constraint for each type.  The risk of
keeping the syntax is that people might interpret it in a way that is
subtly different from what is intended -- witness the confusion in this
case.  But I think the gain outweighs the cost, provided that the
intended definition is clearly explained.


-----Original Message-----
From: Xavier Leroy []
Sent: Tuesday, March 13, 2001 10:32
To: Andreas Rossberg
Cc:; Christophe Raffalli
Subject: Re: [Caml-list] Caml 3.01 : pb with include

I agree with you that the most natural interpretation of the "with
module" constraint is to stand for a bunch of "with type" constraints
on the type components of the modules.  With this interpretation, the
current behavior is a bug.  SML'97 also interprets sharing constraints
between structures as the implied sharing constraints between the type
components of these modules.
To unsubscribe, mail  Archives: