MichaelL_at_frogware.com skrev:
> 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.
Since macro expansion and libraries interact, I see the current
proposal as the "bottom" layer.
> 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.
The discussion on the authors list show, that the current proposal
aims to address these issues:
- seperate compilation and analysis
- independent compilation/analysis of unrelated libraries
- explicit declaration of dependcies
- name space management
It does not try to address other issues. In particular it
doesn't address local modules (called components on the mailing list)
and local imports. Why? Well, my impression of the discussion was that
the authors were pragmatic: one thing at a time. However, they made
sure, that the current library proposal can be extended to include
components later.
And who knows, perhaps it is possible to implement a component
system within the current proposal? E.g. with the PLT module
system, which resemblances the library system somewhat, it is possible
to implement different kinds of components: units and packages (packages
are similar to module system in Chez Scheme).
> 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.
The last paragraph of section 6.2 reads:
An implementation is further allowed to start each expansion of a
library form by removing all library bindings above phase 0.
Can this be interpreted as a license to write macros that expand to
imports? If so you can add your own clauses. I am not 100% sure, that
this is allowed.
> 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.
As long as they can be compiled to the portable syntax, it will still
be possible to get the program running on other implementations.
--
Jens Axel S?gaard
Received on Wed Nov 15 2006 - 11:13:13 UTC