[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] Fixing libraries (was Re: Questions about cond-expand)
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.
Aaron W. Hsu
Aaron W. Hsu | arcfide@x | http://www.sacrideo.us
Programming is just another word for the lost art of thinking.
Scheme-reports mailing list