This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
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