I wanted to present a different take on libraries. I won't submit it as a
formal comment; it's too rough. But hopefully rough doesn't mean useless.
The first sentence of the introduction to the Scheme Report says:
"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." I believe that the current library
design does indeed pile "feature on top of feature" rather than taking a
step back to think about the underlying weakness in the language that
libraries are meant to solve.
I think that stands in stark contrast to how the report tackles most of
its other topics. In nearly all other areas--arithmetic, say, or I/O--R6RS
exposes developers to more of the underlying details so that they can
choose the appropriate level of abstraction themselves. Even records are
being added as a layered interface, with the syntax toward the top. Most
languages--in fact, all mainstream languages I can think of--would only
offer the upper-most syntactic layer to their users.
With libraries, though, the syntax is the only layer we get. And that
syntax, full of reasonable but rather arbitrary decisions, will be frozen
until R7RS.
What do I mean by arbitrary choices? If you look at existing
implementations you get a sense of what else could be done. For example,
rather than requiring you to list all exports explicitly PLT Scheme allows
special clauses in the export section like:
(all-from <module-identifier>)
(all-from-except <module-identifier> <identifier> ...)
(all-defined)
(all-defind-except <identifier> ...)
(prefix-all-defined <prefix-identifier>)
(prefix-all-define-except <prefix-identifier> <identifier> ...)
etc.
PLT Scheme also provides customizable module resolution, and ships with
these options built-in:
unix-relative-path-string
(file path-string)
(lib filename-string collection-string ???)
(planet . datum)
path
The planet option is particularly interesting. It supports automatic
lookup into a shared respository when the module isn't found locally. What
a great idea!
With so many good ideas out there, and with such long periods between
reports, I have to think it is very likely that implementations will start
to adorn library syntax. Since those adornments won't be built on a common
foundation they won't be portable.
I think there's another way to go, though. Imagine, for example, that
libraries were designed the way that records are. Imagine that there was a
procedural layer, and that the syntax was built on top of the procedural
layer. Imagine for a moment that part of the procedural layer looked
something like this:
library-exports
library-locals
library-imports
The adornments that we have now for imports (only, except, add-prefix,
rename) could be implemented as list operations on the list returned by
library-exports; the first two are filters on that list and the last two
are maps. The equivalent to (all-defined) might be coded in terms of
iterating over library-locals; etc.
And, of course, the procedural interface would allow developers (and
implementors) to tap into the library locating process so that mechanisms
like planet could be added--and shared.
With this approach, library syntax would change over time, but the changes
would occur on top of a common foundation. And so the changes would be
portable--or, at least, they'd have a fighting chance.
I'm not serious about the above interface, of course. It was just an
example to illustrate the point. In fact, I think there's a deeper concept
here--a concept related to naming a set of bindings and splicing them into
another set of bindings later on. I think that's exactly the kind of thing
the first sentence of the report is talking about: find the underlying
weakness in the language that stops you from doing what you want to do and
fix it.
I think it's one thing for implementations like PLT Scheme and Chez to
introduce their libraries and modules as black boxes that don't open. I
think it's something else entirely for the report to do that. An
implementation serves its users, but the report serves all
implementations. If an implementation gets something wrong it can quickly
fix it and move on. If the report gets something wrong we all pay the
price until the next report comes along. A layered library interface would
buy us some insurance and some time; it would lower the cost of getting
the syntax wrong right now, and allow the syntax to continue to develop
before we get to R7RS.
As I said, a rough idea but hopefully not useless.
Received on Wed Nov 15 2006 - 00:43:12 UTC