[r6rs-discuss] What's up with the library names?

[Ludovic Courtès]

Hello,

Abdulaziz Ghuloum <aghuloum at cs.indiana.edu> writes:

> Right.  And since it's far more convenient to write (rnrs)
> than it is to write (rnrs (6)), people are going to do that
> by default (I would).  Next thing that happens is that r7rs
> comes out and any library you download would have an import
> of (rnrs) which says nothing about what they target.  So,
> you start the trial and error process (which is what r6rs
> libraries were supposed to handle automatically).  If, on
> the other hand, a library imports (r6rs) and your system
> complains about "(r6rs) library not found", then you would
> at least get a clue about where to look.  And if you do
> change the import from (r6rs) to (r7rs), you would at least
> do that with caution instead of having your import bomb by
> being automatically upgraded.

Symbol versioning as implemented by the GNU linker [0] may be a valuable
source of inspiration.  At link-time, a program is explicitly linked
against a specific version of each shared library depended on.  Thus,
the resulting executable contains the expected version of each of the
symbols it imports:

  $ objdump -T `which ls` | head

  /bin/ls:     file format elf32-powerpc

  DYNAMIC SYMBOL TABLE:
  100265f8      DF *UND*  00000010  GLIBC_2.0   readlink
  10026600      DF *UND*  0000016c  GLIBC_2.0   getgrnam
  10012304 g    DF .text  0000003c  Base        _restgpr_18
  10026608      DF *UND*  00000054  GLIBC_2.2   __fpending
  [...]

At run-time, the loader checks whether the requested symbol/version
combinations are provided by some shared library and bails out if not.
It is up to the library implementor to change the version of a symbol
when its binary interface is changed.

The analogy with R6RS libraries would be that, at the source-level,
Scheme programs would systematically specify the version of each
required library (including the standard libraries).  The Scheme
compiler/linker/interpreter would then return an error whenever one of
the dependencies is not satisfied.

Thanks,
Ludovic.

[0] http://sourceware.org/binutils/docs-2.17/ld/VERSION.html#VERSION