[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keeping the version in filenames
- To: Derick Eddington <derick.eddington@xxxxxxxxx>
- Subject: Re: Keeping the version in filenames
- From: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>
- Date: Fri, 2 Oct 2009 19:02:49 +0300
- Cc: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>, Göran Weinholt <goran@xxxxxxxxxxx>, srfi-103@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-103@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Lad6WHbsTtDEKdyixadQ41bkDvx97k/oFbQxlm+7OB4=; b=mZBp7fYoYZxNCdaLRniWMcs5zimSLgVZU+F8okULngG83hK4EM5XGCvN7q/EZ0mtCS teED9SgzAa2ScKkbaCIXI4/7j7ZaXAC9kgZDZc3fX5823BZW0fH2Z+ipEz1hjWjsgfU2 znO/iffqijfSSJDvI+xUUhE/tfZabcChxD5UE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=haWXMTy55RoJos9MHzYK9VrkE1+u772lR57MuMe4NbTpLiUXbS5ZPmQDT7PmkYU2qS xe51cwwp43Kaaitp/F49ppGk4XaG3QSOJXdE5Kg5pbA/xpr0HdnFyYenOr/6/+KTRb7m lQ/HFAm7yTIAWTWUfoTcEDm8WKkvc6sb/N0CY=
- In-reply-to: <1254488781.18846.179.camel@eep>
- References: <87ocorgl65.fsf@xxxxxxxxxxxxxxxxxxx> <1254488781.18846.179.camel@eep>
On Oct 2, 2009, at 4:06 PM, Derick Eddington wrote:
I look at the issue like this:
This SRFI needs to support having multiple versions of a library
as separate files in the same directory.
I disagree. More to follow.
The only way to accomplish that is by having versions in file names.
There may be other ways like having multiple versions in one file.
[I'm not advocating this either]
It is important to support having multiple versions available so that
different programs which require different versions can both be used.
But different libraries requiring different versions still cannot be
used together. At the extreme case, when every program just contains
a call to "main" of some library, you'd still have to deal with this
issue some other way. That other way, whatever it is, can still be
applied to the situation when you have multiple programs. However,
this SRFI does not describe that other way that solves the problem;
instead, it advocates the nonsolution of having multiple sets of
libraries all available at the same time and for which only certain
combinations work, and only in an unspecified implementation-dependant
manner. This is unacceptable.
If the file naming scheme
does not support versions, the only way to accomplish running the
different programs is to manage configuring the search paths used for
each program so that the correct version is used.
Programs are not the problem. (If Scheme were an operating system,
then all programs would have to run in the same OS instance; how
would I run many programs that have conflicting sets of imports?)
We should be able to know what libraries are present, which includes
knowing their versions because different versions are distinct things,
Ahem. The SRFI draft says what amounts to giving the implementation
the freedom to choose what version depending on some unspecified order
of exploring the transitive closure of imports and what happens during
the traversal. So, if Ikarus traverses the imports left-to-right and
Larceny traverses them right-to-left, we might get combinations of
libraries that can be loaded in one system but not the other. This is
not good. I would rather have this SRFI omit all mention of versioning
altogether rather than specify something that's not good [we have plenty
of that already]. If you have a better idea for how to handle versions,
please put it in another SRFI. I *WANT* all implementors to adopt the
same library file naming convention. This is making it hard.
I want to make sure everyone has thoroughly thought about these points
before sacrificing the qualities of the current draft for the sake of
not being annoyed by file renaming.
I understand your points, but I disagree. The way I look at it
is that R6RS's versioning is not good because it has the wrong
granularity. (and yes, I wish R6RS did not include versions too,
and just because R6RS says libraries have version by no means
says that this SRFI has to support them)
Please leave conflicts, dependencies, etc., outside of this SRFI and
keep it focused on mapping library names to file names only.