/*6.8 Versioning*/

   /Libraries and import clauses optionally carry versioning
   information. This allows reflecting the development history of a
   library, but also significantly increases the complexity of the
   library system. Experience with module systems gathered in other
   languages as well as with shared libraries at the operating-system
   level consistently indicates that relying only on the name of a
   module for identification causes conflicts impossible to rectify in
   the absence of versioning information, and thus diminishes the
   opportunities for sharing code. Therefore, versioning is part of the
   library system.
   /

   /
   /


This part of the rationale makes no sense:

   /Experience with module systems gathered in other languages as well
   as with shared libraries at the operating-system level consistently
   indicates that relying only on the name of a module for
   identification causes conflicts impossible to rectify in the absence
   of versioning information,
   /

/
/Module version numbers are very commonly used at the systems level, that much is true enough. Module version numbers are used to name some installed libraries. Module version numbers often appear in "configure" scripts, "Makefiles," and other software configuration programs.

Experience with module systems in other languages often points to successes in which, within program texts, version numbers are left out and simple names are used for modules. The "hello world" program imports <stdio.h>, not <IEEE stdio.h 1003 1 1998>. The author of the rationale is a guilty of a gross exaggeration, at the least.

The assertion that there are "conflicts impossible to rectify in the absence of [version numbers]" is a very strong claim, an implausible claim, and a claim that is unsupported here.

The rationale also does not address at all the question of why a lexical ordering of lists of numbers is a good choice even if we accept that simple names alone are not enough. Why a list of numbers? Why not a matrix? Why not a generalized tree of numbers? Why not allow characters and strings in, along with numbers? More complicated structures like that occur commonly in the real world, as for example when someone names their revision of a library by copying some other version number, adding a branch name, and then adding a branch version number (e.g., "bsd-1.2-newvmsystemfork-0.1").

All such details of the present design for Scheme seem to refer to some vague analogy to experience with "other languages" and "shared libraries at the operating-system level" and given that that analogy is so poorly presented, there is no rationale presented here at all!

-t

(p.s.: I care not if, as a pragmatic condition of getting lots of open source Scheme modules in various package systems, a library naming system that includes version numbers is widely adopted. I care only that such is not made normative for Scheme itself.)



_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to