[ERR5RS] Library versioning

[Lynn Winebarger]

There is a substantial amount of dislike for the R6RS library
versioning scheme.  I agree with the dislike of that approach, but
ignoring the problem versioning is intended to solve will not make it
go away.
   I outlined my take on the issue on the wiki:
http://scheme-punks.org/wiki/index.php?title=Talk:ERR5RS:Dynamic_Loading_of_ERR5RS_Libraries
particularly:

     OLW 19:19, 12 September 2007 (PDT) - People raised on lower level
languages tend to view libraries as call-by-need constructs. [....]
The main concern should be that two modules using a supposedly common
library should be able to use the library's interface to communicate,
and that requires consistency between the two. The versioning approach
taken by R6RS is supposed to allow the user to declare that certain
versions of the library's implementation are semantically "close
enough" to what their code uses to successfully communicate at
run-time.

I think the following comment taken from Chris Hanson's vote against
R6RS ratification is valuable:

  The module system is basically a way to tell the linker how to
  construct programs from parts.  Rather than invent a new language to
  do this, it's possible to build the linker such that the programmer
  can insert code to control aspects of the linking process.  Such code
  could do _more_ than the current module system does, and because of
  the added expressivity, it could do so more concisely in many cases.
  For example, I sometimes use a trivial module system in which names
  starting with "%" are local, and all other names are exported.  This
  is a trivial program to write, and doesn't depend on the details of
  the names, but it can't be said at all with the proposed module
  system.

My interpretation of this in the context of versioning is that the
library should be made responsible for "rendezvous" code that would
determine, at link time, whether the versions of a given library that
two or more dependent libraries/modules were compiled against are
compatible enough.  This seems like a neat approach, though whatever
entity that is requiring the two libraries might also need to specify
that they must link to the same shared libraries (or not).  I.e., in
the diamond, we would have the top and bottom controlling the linking
instead of the sides.

Lynn