This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
Per Bothner wrote:
> Right, but we're talking about "named libraries". Once something has
> a name, you can give it a URI.
True - and as an only tangentially relevant aside, there are tricky
problems with naming and equivalence that crop up about here. Does the
URI refer to the library independent of its physical location, or does
it refer to a particular location containing a representation of the
library? The latter is an easy choice - the former is hard because you'd
need some means of comparing library forms for equivalence... anyway,
there are issues with what library names *denote* that aren't totally
obvious.
> 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.
We have an even more standard way of naming them: (X A), (X B) and (X
C). You can even represent names with components containing "/" this way.
>> 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.
I was not talking about a collection of libraries: I was talking about a
collection of forms contained within a single library. I am advocating
S-expressions for aggregating forms within a library - you are
advocating using a file to aggregate forms within a library.
>> A file is not always the best granularity for a library
> True, but we're trying to standardize a useful portable basic feature.
Files are not portable. (If you'll pardon the pun.)
>> - 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?
I can't argue this point further as I have no data in either direction.
> Right, though this not directly handled by the proposal. It can
> be handled by using a compound library importing and re-exporting
> smaller libraries.
That's a possibility, but it only works for multi-file libraries whose
parts have no circular dependencies. Perhaps a future SRFI can specify a
mapping from multiple files to a single library. In general, mapping
libraries on to files in either direction seems like a headache to me -
one that is deferrable if we use an existing Scheme data structure and
mention non-scheme constructs as little as possible.
>> (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.
These aren't nested libraries - they're sequential. Actually, the point
was that it's unclear what the code snippet means. Are there two
libraries in the snippet above, or just one? Does opening "mylib" cause
a side-effect, or not? There's no confusion if S-expression library
containers are used:
(library "mylib" "scheme://r6rs"
(define library (compose write list)))
(library "otherlib" "scheme://r6rs"
(define number 17))
vs.
(library "mylib" "scheme://r6rs"
(define library (compose write list))
(library "otherlib" "scheme://r6rs")
(define number 17))
Regards,
Tony