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
[Caml-list] recursive modules redux, & interface files
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-03-22 (00:23)
From: Patrick M Doane <patrick@w...>
Subject: Re: [Caml-list] recursive modules redux, & interface files
Hi Xavier,

Your example demonstrates that a proposal for such an extension
should be more explicit about how it should work.  I had a particular
implementation in mind from my post yesterday:

  For every module definition M that has a signature S
    For every type definition t in S that contains optional
               type-information and is not defined in M
      Add the type definition of t to M (preserving the order from S)

  Proceed with the usual algorithms for type checking, matching
      structures,  etc.

I think this should work properly. Anything I might have missed? You seem
to elude to special cases that are not immediately obvious.

I agree that it becomes kludgy to remove the separation that currently
exists between structures and signatures.  However, as a programmer
maintaining the duplicate types also seems kludgy . After all, the
compiler has the information available, why doesn't it use it?

This seems to be a case where a compromise between theory and practice
should be explored.


On Wed, 21 Mar 2001, Xavier Leroy wrote:

> It becomes practically inconvenient when the signature is known at the
> time of the structure definition:
>         module M : sig type t = A | B ... end =
>           struct type t = A | B ... end
> Which is the case with interface and implementation files.
> In this case, one could envision an automatic completion of the
> structure / implementation file so that concrete type specifications
> from the signature do not need to be implemented in the structure.
> Doing this right is not obvious, though.  First, it's not enough to
> say that a concrete type spec does not need to be matched in the
> structure.  This would type-check
>         module M : sig type t = A | B end = struct end
> but not
>     module M : sig type t = A | B  val v : t end = struct let v = A end
> In other terms, the unmatched concrete type specs in the signature
> need to be somehow reintroduced in the structure definition, so that
> other parts of the structure may refer to them.  While I think it can
> be done in most practical cases, it's a bit of a kludge and I'm not
> sure how to do this in all cases.
> Is the practical value of this kludge enough to forget that it's a
> kludge?  Can't we live with the current duplication of concrete type
> definitions in the name of systematic, principled module systems?  
> I really don't know.

To unsubscribe, mail  Archives: