Abdulaziz Ghuloum <xxxxxx@gmail.com> writes:

> On Oct 1, 2009, at 6:59 PM, Göran Weinholt wrote:
>
>> So is the idea that I would be keeping versioned filenames in my
>> bazaar
>> repository, or would they be renamed to include a version by a package
>> manager?
>
> We should not assume the existence of a package manager.  Also, you
> won't be using a package manager when working with your own libraries,
> right?  Usually, you work on your libraries locally and then, in a
> separate step, package it together for distribution.  You won't want
> to add the package manager to your workflow.

That's a good point. So what problem is solved by keeping the version
inside the filename? I read something about a distinct mapping of
filenames to library names, but then I'm not sure what problem that in
turn solves. If you want the version number then it's in the file, which
is usually not far away.

Having the version in the filename also duplicates information, which in
my experience always gives you the problem of keeping the duplicated
information synchronized. Obviously the library name is duplicated in
the filename, but it changes much less often than the version number.

There is something of a feature-creep in this SRFI as it currently
stands. As I see it, the idea is to standardize the widely implemented
library file locator algorithm and work out all the edge cases. Keeping
the version number in the filename is not widely implemented, and
creates new problems by itself. Remove that feature and I think we will
have a less controversial SRFI that is also compatible with existing
Schemes and libraries.

I'm all in favor of library versions and version references. I use them
myself, as a courtesy to those who want to use my libraries, and because
I want to be able to change the meaning of exported bindings without
causing people too much trouble.

Is the idea that filenames should contain versions so that multiple
versions of a library can co-exist in the same directory? If a library
developer wants to do that, he can simply append a major version to the
end of a library identifier, something like this:

 (foo jpeg (0))   foo/jpeg.sls   initial version (0 is the minor)
 (foo jpeg (1))   foo/jpeg.sls   second version, supports more formats
 (foo jpeg1 (0))  foo/jpeg1.sls  third version with a much better API

If he wants to he can even make it so (foo jpeg) is a compatibility
wrapper around (foo jpeg1). Such a wrapper would be very useful for
anyone changing a program to use the new library, because it would show
exactly what changes are necessary. And if the developer was careful,
there will not be any point in keeping (foo jpeg (0)) around when you've
got (foo jpeg (1)).

This is much less tedious than requiring that every part of a version
reference always must be included in the filename, and it leaves the
individual developer free to choose what he and his users need. I can't
imagine anyone being very happy when they discover that to use R6RS's
version feature they need to forever keep renaming their files.

>> Also, SCHEME_LIBRARY_SEARCH_PATHS is rather long. How about SLSPATH?
>
> I think it is long.  I'd be happier with SCHEME_PATH (Derick likes
> plurals and hates unix) or SCHEME_LIBRARY_PATH.  The work SEARCH is
> definitely not adding anything you don't already understand from the
> word PATH.

I completely agree. Your proposed names are much more idiomatic.

Regards,

--
Göran Weinholt <xxxxxx@weinholt.se>
"... for these truths hold good for everything that is ..."