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.

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.

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.  Having devised sufficient
facilities for libraries in the core, SRFI's can standardise on a
library syntax.  By removing restrictions, such as the artificial
barrier between the library engine and the evaluation engine, we obtain
a language that is both more expressive and simpler.

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.

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.  It has the additional bonus that the
language gets more powerful, more SRFI's can be written in pure Scheme
(because of the reflective abilities), and programmers that really
dislike the library syntax can fix it.  IOW, freedom, and possibility to
continue language research, in Scheme.

Panu

--
personal contact:	xxxxxx@helsinki.fi, +35841 5323835
technical contact:	xxxxxx@iki.fi, http://www.iki.fi/atehwa/
PGP fingerprint:	0EA5 9D33 6590 FFD4 921C  5A5F BE85 08F1 3169 70EC