[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] "module" vs. "library"
Am 05.07.2011 06:06, schrieb John Cowan:
> Andre van Tonder scripsit:
>> Unit, component, package, structure, assembly, collection, container,
>> aggregation, grouping.
> Unit, component, package, struct(ure) are used in Schemes/Lisps in other
> ways. Collection and container suggest runtime objects. Assembly is
> heavily overloaded, but might have been good if the CLR hadn't used it.
> Aggregation suggests an accidental rather than intentional combination.
> Namespace (which you didn't mention) is already in use.
> But keep going.
What about "define-library"? It might be slightly confusing as it sounds
a bit procedural for a purely syntactic construct, but it does not seem
to clash with any existing implementation (as far as a quick Google
search reveals, at least) and preserves the "library" term, which is
common, well-known, clear and in line with previous Scheme specs (R6RS
and, in a way, R5RS' usage of the term "library procedure").
Having said that, I don't find "extensibility" to be a particularly good
argument for the design of a standard module system. In fact, I actually
even find it to be quite harmful. The whole point of a standard module
system for Scheme is portability: to be able to share code among Scheme
implementations in a structured way. As such, it should stay fairly
static and only rarely be changed or added to, if ever. Making the
module form extensible, on the other hand, opens the door to possibly
incompatible implementation-specific extensions which potentially
decrease the portability of what is actually mainly thought as a
portability construct; not because these extensions make portable code
less portable, but because it encourages programmers to narrow the
portability of their code to a subset of the Scheme landscape for mere
To be honest, I actually think that the restricted R6RS library form is
actually the right approach it that it actively *prevents* anybody from
substantially adding to it, which essentially guarantees that it will
work mostly the same on all implementations implementing it - but YMMV,
naturally. (And as to the possible extensions that Alex listed: AFAIK,
R6RS libraries at least support versioning, and lazy loading might be
doable as an extension to the "import" form.)
Sorry if some of my comments are uninformed at points.
Scheme-reports mailing list