I guess a shell script could go through a directory and rename all my libraries appropriately... so it wouldn't be necessary in any Scheme implementation.
On Thu, May 14, 2009 at 9:53 PM, Ramana Kumar <[email protected]> wrote: > 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 >> ---------------------------------------------------------------- >> >> >
