Re: [Scheme-reports] "module" vs. "library"

[Denis Washington <denisw@x>]

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 
convenience.

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.

Regards,
Denis Washington

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports