Thanks for your message, Derick. A nice (probably non-portable) feature, if library name = file name is the way to go, might be to make unnamed library forms take on the name of the file they are in. or even to dispense with the library form altogether with .sls files (just assume the contents are a library). this thought is coming from someone who renames a file and forgets to rename the library inside it.
On Thu, May 14, 2009 at 9:35 PM, Derick Eddington <[email protected]> wrote: > 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 > ---------------------------------------------------------------- > >
