> I prefer Hendrik's suggestion of explicitly including a signature to the
> earlier suggestion of automatically including types from a signature
> constraint.  If you automatically include types from a signature
> constraint, the signature stops being a constraint, and you might match
> signatures that you never intended to.

> I assume Hendrik is considering the case where an interface already
> exists, and you're writing the implementation.  

Just curious, but how would you treat this?

module type TEN = 
  sig 
    module PLAYER : sig type t = Andre | Pete | Ivan | Cedric val name :
t -> string end
    exception Not_Ex_No1 of PLAYER.t
    type u = PLAYER.t -> PLAYER.t
  end

module Ten = 
  struct 
    includesig TEN
    ...
  end

Reject?

Friendly, 

Tom

Dave Berry a écrit :
> 
> To be more general, perhaps specifications could be interleaved with
> declarations in modules.  In addition to including entire structures,
> this would let you specify the type of a function separately from it's
> implementation:
> 
> val map: ('a -> 'b) -> 'a list -> 'b list
> let rec map f l =
>   match ...
> 
> This is one aspect I like about Haskell's syntax.  I find it clearer
> than the current:
> 
> let rec map (f: 'a -> 'b) (l: 'a list) =
>   match ...
> 
> 
> type coleur = Rouge | Vert | Bleu
> (both type and implementation exported)
> 
> type animal
> type animal = Chien | Chat | Oiseau
> (only the type is visible outside the module)
> 
> I've no idea how easy or hard it would be to incorporate this into
> either the semantics or the implementation of the language.  But from a
> pragmatic point of view, it seems a relatively clean change.
> 
> Dave.
> 
> -----Original Message-----
> From: Hendrik Tews [mailto:tews@tcs.inf.tu-dresden.de]
> Sent: Thursday, March 22, 2001 12:03
> To: caml-list@inria.fr
> Subject: Re: [Caml-list] recursive modules redux, & interface files
> 
> What about changing
> include, such that including a signature into a structure
> includes all types and all exceptions?
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr