Re: Reified modules, module = environment?

[bear <bear@xxxxxxxxx>]

On Tue, 10 Jan 2006 atehwa@xxxxxxxx wrote:

>I'm not sure what to think about this proposal.  On the one hand, it
>provides a long-yearned facility with a standard syntax, simple, easy to
>understand and relatively generic.  On the other hand, it is
>un-Scheme-like in many ways -- probably because many of the existing
>implementations, after which this SRFI has been modelled, are that too.
>Modules are not objects.  They are identified by strings, not even
>symbols.  The syntax doesn't seem to be very generic nor neutral about
>execution phases: it presupposes there to be two.  The library system is
>accessible to neither phase; both phases must operate "within it".  The
>syntax is not integrated with the core language, but is an add-on.

I have something of the same issue.  It seems strange and un-lispy to
see such a strong type restrictions on things like module identifiers,
and also strange and unschemely to be introducing new objects (modules)
into the language without making them first-class (can be returned from
functions, stored in structures, etc).  Opacity is directly at odds,
from first principles, with the reflective and analytic and code-walking
properties that have made lisps into such strong languages historically,
and the module system syntax comes with many many restrictions that IMO
do not belong in a language that tries so hard to remove such restrictions
from all other expressions.

> What I find particularly problematic is that here _protocol_ is
> specified before _mechanism_.  First-class reified continuations were
> specified before exception and indeterminism facilities, because
> continuations are the mechanism, and exceptions are a protocol for using
> that mechanism.  Vectors were specified before records, because vectors
> are the mechanism and records are a protocol for using that mechanism.
> Admittedly, define-syntax (a protocol) was specified before specifying
> what syntax transformers are, but now we have Andre's simple, elegant
> and versatile macro mechanism that allows us to bring syntax and syntax
> transformers back into the realm of Scheme basic data types.

It's a good and worthy thought.  But what simple and clean mechanism
suffices for the implementation of modules as a protocol?  (I believe
that first-class mutable environments, which are consistent with
R5RS's requirements for environments, do suffice, btw...)

> Remember this sentence?  "Programming languages should be designed not
> by piling feature on top of feature, but by removing the weaknesses and
> restrictions that make additional features appear necessary."  Scheme
> people should think as much as possible how to provide a powerful enough
> core that extensions can be made in Scheme.

I think so.  But I also think that a particular protocol/implementation
of modules should be provided and standardized on, simply for the sake
of portable code.

> It happens that R5RS already has a facility that _almost_ implements
> modules.  This facility is called an "environment".  Environments
> contain values for symbols, exactly like modules do.  They only lack a
> few properties to be used as full-fledged modules: the ability to create
> new, empty environments and the possibility to query an environment for
> the bindings it contains.  If we continue on the track now chosen, we
> will have a language full of half-fledged utilities, all somewhat
> similar, all restricted in different ways: environments, modules, hash
> tables, objects, and records.

There is one additional, and very important, facility required of
mutable environments if we intend to use them as a mechanism for
implementing modules -- we need to be able to make syntactic bindings
in our modules visible to code.

> That's not a nice state to be in.  How about specifying the mechanism in
> the report, and leave protocol to SRFI's?  It's slow, but that's the
> Scheme way, at least it has been.

I think that SRFI's are probably the wrong venue for standardizing.  I
would look to R6RS for a fundamental mechanism that *allows* the implementation
of module systems, and also a standard or default module system.

				Bear