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?)
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 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. Is there any other solution? On Thu, May 14, 2009 at 5:54 PM, Derick Eddington <[email protected]> wrote: > On Thu, 2009-05-14 at 10:55 +1000, Ramana Kumar wrote: >> I think a standard interface for resolvers (i.e. specifying where to >> find the library forms that define the libraries you want to import) >> would make for a useful SRFI. > > I've been working on an SRFI proposal for resolving libraries to files. > I submitted it over two months ago and waited one month for the editors > to review it and post it as only a draft so it could be publicly > reviewed and discussed, but they must have been too busy because they > never got back to me, which actually turned out to be for the best, I > think, because Aziz pointed out a serious defect with combined version > constraints of imports and having multiple versions of a library > available. I very much want to support having multiple versions of a > library available, so I'm currently stewing about what can and should be > done about it, and so I told the SRFI editors to wait for me to get back > to them. Other than this problem, I think the rest of it (modulo a few > minor things which just need to be touched-up) is ready to go. > > What I've got so far is at: > > https://code.launchpad.net/~derick-eddington/+junk/library-files > > Everything in it about versioning will be changing somehow, maybe > totally removed. > >> We can make a list of possible resolvers, if that would be helpful: >> - in a directory "/some/path": look for files >> /some/path/library-name.ext with one library in each file. maybe can >> choose the extension, and some function on the filename. >> - in a file "/some/path/to/file.ext": look for library definitions >> within the file >> - both of the above could use urls as well as filesystem paths >> - in a database >> >> Would there be any problems with trying to standardize an interface >> for this kind of thing? > > Probably: complexity, corner cases, long-term robustness, usefulness for > unforeseen integration with unknown things, making everyone happy, etc. > > -- > : Derick > ---------------------------------------------------------------- > >
