[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reified modules, module = environment?
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.