[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modules

John Ramsdell, Fri, 23 Feb 90 13:22:04 EST:
> Before I form an opinion on this proposal, please answer the
> following question.  Many module systems provide some sort of generic
> or parameterized module facility.  Standard ML has functors and Ada
> has generics.  Does this proposal provide parametric modules and can
> they be instantiated using a set of mutually recursive module
> declarations?  If parameterized modules were left out purposely,
> please explain why.

In short, no.  The module system is not that ambitious.  We are using
modules to provide a static mechanism for controlling the access that
different parts of a program have to each other.  We are not using
modules to provide data abstraction or (object-oriented-ish) classes.

I can think of three kinds of things offhand that one might want to
parametrize a module over: types, values, and implementations.  Type
parametrization isn't as useful in Scheme as it is in ML or Ada
because of Scheme's latent typing.  The module system lets you
parametrize over implementations (by means of interface
specifications), but only statically -- there is no way to dynamically
select a particular implementation of an interface specification.

It's true that you gain more expressive power by introducing
parametrized modules.  It's a tradeoff; the penalty is a more
complicated semantics.  You can keep on adding expressive power by
going all the way to first-class modules, but if you go that far
you've pretty much given up hope on static checking.  

Where to draw the line depends on one's goals.  Among Scheme Xerox's
goals, simple semantics and static checking outweigh the additional
expressive power of parametrization.  What is appropriate for RNRS
might well be (and almost certainly will be!) different.