Reified modules, module = environment?
atehwa@xxxxxx
(10 Jan 2006 16:07 UTC)
|
Re: Reified modules, module = environment? bear (10 Jan 2006 19:21 UTC)
|
Re: Reified modules, module = environment? bear 10 Jan 2006 19:20 UTC
On Tue, 10 Jan 2006 xxxxxx@sange.fi 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