Aaron, What you are arguing below amounts to "let's just use the Chez module system." We had a huge amount of discussion about this already and a fair vote, and the result is the only sensible possibility - a lowest common denominator module system. Chez modules cannot be implemented by every other system, nor can Scheme48 modules, but the R7RS define-library form can. Without fail, every time anything related to modules comes up, you have replied stating how Chez does it, which is irrelevant. I would ask you stop this. It's distracting and it's too late to revisit this. The confusion with the top-level forms stems in part from vaguely written tickets, and in part from the fact that the top-level is inherently confusing. We will vote to clarify or remove the confusing forms - their equivalents were not in R6RS and they are not essential to a useful and productive library system. -- Alex On Fri, Sep 7, 2012 at 1:10 AM, Aaron W. Hsu <arcfide@sacrideo.us> wrote: > Dear Working Group: > > I hope to bring this discussion to the fore as I believe that we as a > group have made some errors in the approach that we have taken to > dealing with these libraries. I believe we have a chance at this moment > to rectify the situation and I hope that we will do so. > > As a history of the issue as I see it, we have a library system > that we have defined in special language requiring it to be static. > We have also defined a set of library clauses which are static. > Additionally, we have voted to allow specific exception that allow > for these forms to appear "at the top-level" but we are not clear > about this, and the language is ambiguous. Moreover, this will > likely lead to at least three different concepts of forms like 'include' > in any reasonable Scheme implementation. > > However, I argue that this is not how Scheme implementations currently > do this, and moreover, that we have an opportunity to create a simplified > approach to this that is at the same time richer and more unified. > It is also backed up by existing implementation strategy and does > not restrict the implementation strategy of Schemes which may have a > slightly different picture than presented here, because the > strategy taken by these Schemes is observationally equivalent to the > behavior required by my suggestions here. > > We really have two problems. Firstly, we have a library system that > is completely outside the rest of the standard, and is unified in no > ways with the rest of the system. This requires special language to deal > with this fact. Secondly, we have restricted the system to such a point > and in such language that users are unnecessarily restricted. > > I would like to introduce my suggested revisions that fix these > problems and clean up the language and standard by first talking > about what an existing Scheme does to accomplish this. In Chez Scheme, > The library form is just another Scheme form, but it accurately implements > the semantics of the R6RS library form. Moreover, the export, > import, and include forms, among others are also valid Scheme forms. > These work as might be expected as forms. The library form has its > own special clauses for export and import (which are not the same, > but behave the same, as the export and and import forms of the language). > In other words, Chez Scheme has provided the entire library system > with no further language complication than was necessary to introduce and > define the meaning of the forms. > > One of the nice consequences of this is that libraries can be used > to implement richer systems like a library system that separates > implementation from interface, or one that stores documentation and > so forth. This is an important principle in Scheme. User created > extensions should not be underpriveleged. They should work and feel > just like an implementation built-in. We should be able to implement > our own versions of things using possibly simpler primitives provided > by the Scheme language. These versions should play nicely, within > reason, with each other. > > We can clean up the entire mess that we have created here by changing > a few things. By making these changes, we will be able to unify the > library system and its parts with the rest of the language. > > 1. Define library as just another Scheme form that creates a > close world. We can keep the syntax and such that we have already > chosen, and we can also keep the requirement that these clauses > of a library are static and not affected by the world created for > code by the library. > > Making this change immediately removes the need to think about > the library form as a static thing separate from the rest of the > Scheme world. However, it still makes it a top-level, static form > that is open to analysis. > > 2. Define 'include', 'import', and the other forms as regular Scheme > forms which have their obvious semantics. This means that we can > do useful things like (let () (import ...) ...) and the like. This > immediately makes our language richer, and provides primitives that > are not implementable in the R7RS Small language. More importantly > for this discussion, not only have we made the users life better, but > we have also simplified the standard by eliminating the need to discuss > these forms as separate, special entities for the top-level, because > these forms can be used directly in any REPL. This gets rid of the > problem we have right now that has introduced ambiguity. > > 3. Change the language of the 'library' form to define the behavior > of the static library clauses in terms of their language form counter > parts. This unifies the semantics of these two forms and simplifies > things down so that a single semantics can mostly suffice for both > the static library forms and the Scheme language forms. > > 4. Unify the top-level of files and REPL to have at the minimum > the 'library' and 'import' forms. This is all that is needed to > have an usable system. That is to say, we define the environment of > REPLs and files meaningfully, with at least this minimum intersection. > With this minimal section, systems that load files statically can actually > still load libraries without any special expansion, because the only > two forms that are in the environment are import and library. This > means that we have a semantics that, while defined in terms of language > forms, does not preclude implementations which are equivalent, but > slightly different in approach. > > 5. We can create a separate (scheme libraries) library to hold these > forms, so that they need not pollute the user level code unless > the user wants them. This is not necessary, but could be a nice > separation of features. > > By making these changes we simplify the language of all the library > system to require only talking about it as a special form of the language, > and we can unify the library system with the normal concept of a > Scheme environment and Scheme code, because a library is just > Scheme code. We are friendly to implementors, who already must implement > a top-level for the REPL. We provide more power to the users, and > make it easier for WG2 to specify extensions to the library system that > allow for user defined library extensions to exist comfortably with > one another. Furthermore, we match the behavior of existing implementations > better, without being overly specific about details that might > force one implementation strategy over another. > > The overall effect is that we have removed and addressed the > ambiguities mentioned beforehand, and have at the same time dealt > with what I consider a glaringly ugly bit of standards writing on > our part. The result is simpler and cleaner. > > Yours truly, > > Aaron W. Hsu > > -- > > Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us > Programming is just another word for the lost art of thinking. > > _______________________________________________ > Scheme-reports mailing list > Scheme-reports@scheme-reports.org > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
