caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Claudio Russo <crusso@microsoft.com>
To: caml-list@inria.fr
Cc: frisch@clipper.ens.fr
Subject: RE: first class modules (was: alternative module systems)
Date: Mon, 8 Jan 2001 07:11:12 -0800	[thread overview]
Message-ID: <112C6E8A1B25D34BB27D48D2FD2E96CFC9429A@TVP-MSG-02.europe.corp.microsoft.com> (raw)


(This was a response to Xavier and Mosml hackers, but I've been asked to
forward it to the list).

> Hi Claudio,
> 
> > BTW, in Moscow ML, the "open" construct is integrated more naturally
> > as a special form of declaration, plus a side condition that
> > disallows an open declaration from appearing within the body of a
> > functor (for soundness reasons). This lets you open first-class
> > modules at top-level and within substructures, which can be more
> > convenient.
> 
> That sounds interesting.  I was thinking exactly along these lines.
> Do you have this written down somewhere?
> 
> Xavier

In Moscow there is no separate open expression, just a new form of
structure binding that let's you deconstruct a
first-class module (there is a similar form for functors):

<strbind> := ... | <strid> as <sigexp> = <exp>

This lets you write declarations like


structure Bar as S = if .. then .. else ...;

wherever an ordinary declaration can occur.

This is actually more general (and convenient) than the open construct
because it lets you open first-class modules  at top-level and within
structure bodies, not just within Core expressions. If functors are
always generative, this is ok, but it interacts badly  with applicative
functors (programs can go "wrong"). 
To avoid this, in Moscow we simply place a syntatic restriction on
functor bodies: 
"the body of any functor (whether applicative or generative) cannot
contain a structure level declaration of the 
 above form,  *unless* that declaration occurs within a dec in a Core
"let <dec> in <exp> end" expression"

In the examples below, the structure Ok is legal, the functor Wrong is
illegal but the functor Ok is legal.

signature S = sig type t val f:t end;
structure A = struct type t = int -> int val f x = x+1 end;
structure B = struct type t = bool  val f = true end;
structure Ok as S = if ... then [structure A as S] else  [structure B as
S] (* legal *)
functor Wrong(val b:bool) = 
struct structure C  as S =if b then [structure A as S] else  [structure
B as S]                            
end (* ilegal, because of "open" within immediate structure binding *)

functor Ok(val b:bool) = 
struct val c = let structure C as S = if b then [structure A as S] else
[structure B as S]
	                                in  ...
                                      end
end (* legal again, because "open" is within Core let. *)

I've got a formal revision of the SML definition,  if anyone is
interested, just ask.

The Mosml doc also describes the syntax in more detail (if I recall
correctly).
Of course, it's probably possible to come up with a more permissive
restriction, but I like this one because its simple.

Cheers,
Claudio




 




             reply	other threads:[~2001-01-08 17:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-08 15:11 Claudio Russo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-10 10:32 Claudio Russo
2001-01-09 13:36 Claudio Russo
2001-01-08 14:59 Claudio Russo
2001-01-08 13:48 Claudio Russo
2001-01-08 10:45 Claudio Russo
2001-01-08 12:17 ` Alain Frisch
2001-01-07  0:20 Alain Frisch
2001-01-07 23:26 ` Markus Mottl
2001-01-08 10:42 ` Xavier Leroy
2001-01-10  0:40   ` Brian Rogoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=112C6E8A1B25D34BB27D48D2FD2E96CFC9429A@TVP-MSG-02.europe.corp.microsoft.com \
    --to=crusso@microsoft.com \
    --cc=caml-list@inria.fr \
    --cc=frisch@clipper.ens.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).