On Thu, 2009-05-14 at 18:14 +1000, Ramana Kumar wrote:
> I'm glad to see you've put so much work into this =) I hope your issue
> with multiple versions is solved soon. (Did you write exactly what it
> is anywhere?)
Yes, but it's threaded through private emails. Basically:
"foo.2.sls"
"foo.3.sls"
(import (foo ((>= 2)))
(foo ((<= 2))))
Depending on which import gets processed first, the entire import set
may or may not be satisfied. All the possibilities of version
constraints combinations and transitive imports make it complicated
because you can't know the entire import set until you already commit to
a particular version, but that version might cause a set which doesn't
work, while a different available version of the same library would
cause a set which does work. Making combined version constraints work
with multiple versions available gets so twisted that knowing what
versions you're actually going to import gets ridiculously confusing.
Even with a tool to tell you what versions you'll get, trying to fiddle
with imports to get the set you want becomes an unacceptably contorted
ugly task. The environment procedure (i.e. run-time dynamic imports)
and internal imports (like Ikarus's) make it more complicated. Separate
compilation then makes it even more complicated.
I'm probably going to totally ditch R6RS's version constraints and
invent some other versioning, but that adds a lot more work... Or maybe
I'll ditch multiple available versions altogether and let it be solved
over time so we can just have some file naming standard with the other
qualities my proposal has.
> This is probably now a new topic: What about multiple libraries per
> file? The proposed SRFI 100 explains that the idea is not worthwhile.
> There are two uses which may have other solutions that you can tell me
> about:
> 1. In the absence of meta define, a small library you can import can
> let you share code between macro definitions. It can be a hassle to
> have to keep this small library in a separate file.
I hear what you're saying, but I don't think it's worth losing the
advantages of single-library files. As the document says of itself, "it
is also intended to be useful for building upon to create software for
managing library files". I see the ability to simply 1-to-1 map file
names to library names, which requires single-library files, without
needing to read the contents of files or even possess the files, is a
desirable quality for "building upon to create software for managing
library files" as well as for humans. Single-library files allow simply
listing the names under a directory tree to know all the libraries
contained. I don't want the file names to only name a file, I want them
to also name a library. The utility procedures my design provides take
advantage of this.
> (I guess this is
> related to the next point).
> 2. To transfer a library that actually has a few dependencies, you
> need to send multiple files. I guess this is what "tar" is for.
Yes, that's my opinion.
> Is there any other solution?
OS package repositories, like Ubuntu's etc. Descot [1].
My design is aimed at making things simple for large scalability, not at
making things a little more convenient for small scale.
[1]
http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/13553a6ee843449e
--
: Derick
----------------------------------------------------------------
