[MLton] Minor front-end extension

[Alain Deutsch]

Right. I was thinking of having a way, on option only of course, to enforce
a simple coding rule for the common case structure S : sig = struct ... end;
But you are right, we also probably want to deal with functor F(): sig =
struct ... end; And yes, there would be a way to work around this using one
of the forms you listed.

The goal would be to help our junior developper think about writing
signatures.

An objection could be that this does not look very general and orthogonal.

--
Alain Deutsch, CTO              tel.: +33 (0)1 49 65 32 64
PolySpace Technologies          fax.: +33 (0)1 49 65 05 77
mailto:deutsch@POLYSPACE.COM    http://www.polyspace.com


> -----Original Message-----
> From: Stephen Weeks [mailto:sweeks@sweeks.com]
> Sent: Wednesday, August 11, 2004 6:30 PM
> To: Alain Deutsch
> Cc: MLton@mlton.org
> Subject: [MLton] Minor front-end extension
> 
> 
> > I was thinking it could be very useful for us to have an option
> > which rejects toplevel structure definitions without signature
> > constraints.
> 
> This feels like a very strong restriction.  I guess the motivation is
> to prevent accidentally exposing identifiers that should be hidden?
> Would you require the constraint to be syntactically in the structure
> binding, as in
> 
> 	structure S: SIG = ...
> 
> or would you only require that the components of the structure have
> been constrained at some point?  Consider the following.
> 
> * structure T: SIG = ...
>   structure S = T
> 
> * structure T: SIG = ...
>   structure S = T.U
> 
> * structure T: SIG = ...
>   structure S = struct open T end
> 
> * structure T: SIG = ...
>   structure S = struct open T.U end
> 
> * structure S = struct ... end : SIG
> 
> * structure S = let ... in struct ... end : SIG end
> 
> * functor F (): SIG = ...
>   structure S = F ()
> 
> * functor F () = struct ... end : SIG
>   structure S = F ()
> 
> It's not entirely clear to me what you want to do about structure S in
> the above situations.