[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: put library <body> at top-level
Tony Garnock-Jones wrote:
"Source code in files. How quaint. How 70's." (Kent Beck)
If prefer, replace "file" with "something that has a URI".
Scheme code doesn't have to live anywhere in particular - it can be
sourced from anywhere, from files, from stdin, from an email message,
from a database - the only constraint on scheme code is that it is an
Right, but we're talking about "named libraries". Once something has
a name, you can give it a URI.
If you have multiple named resources A, B, and C nested within a
resource X, then we have standard way of naming them: X/A, X/B, and X/C.
This all works best if A, B, and C are separate "units of characters",
rather than being concatenated together.
List syntax is already suitable for sequencing S-expressions within an
S-expression. Files provide a second-class means of sequencing
S-expressions. Recovering a complete list of S-expressions from a file
requires some small-but-nonzero amount of work.
Beside the point: a collection of libraries is not a "sequence": It is
a *mapping*, from names to libraries.
A file is not always the best granularity for a library
True, but we're trying to standardize a useful portable basic feature.
- sometimes many
small libraries are best expressed in a single file,
I think this is fairly rare, and not a very important use case.
If they're small, why should they be separate libraries?
> and sometimes a
single library is best expressed in multiple files.
Right, though this not directly handled by the proposal. It can
be handled by using a compound library importing and re-exporting
The scoping of the |library| form can be unclear if forms /following/
the declaration are to be considered part of the library:
(library "mylib" "scheme://r6rs")
(define library (compose write list))
(library "otherlib" "scheme://r6rs")
(define number 17)
The proposal doesn't support nested library forms, so I don't see
why this is relevant.