[Larceny-users] finding libraries

[William D Clinger]

Marco Moggie wrote:
> Of course I can write a shell script that
> makes use of an environment variable to build
> the "-path" argument, but... make it simple!

You could, for example, edit the startup.sch file
documented in sections 3.2.4 of Larceny's User
Manual.  If you prefer to use an environment
variable, then you could edit the shell scripts
provided with Larceny.

> The second problem is that Larceny neither
> supports loading a library for "(uriel lang)"
> from the file:
>
> <dir-in-path>/uriel/lang/main.sls
>
> nor loading "(uriel lang compat)" from:
>
> <dir-in-path>/uriel/lang/compat.larceny.sls
>
> at least I have found nothing for this in the
> documentation.

Larceny's mapping from library names to file
names is documented in section 5.4 of its User
Manual.  Larceny's mapping is similar to the
mapping that was suggested in a draft of the
non-binding appendixes to the R6RS but was
withdrawn from the non-binding appendixes that
the R6RS editors regarded as final.  You can
put (uriel lang) in either of

    <dir-in-path>/uriel/lang.sls
or  <dir-in-path>/uriel.sls

Similarly, you can put (uriel lang compat) in

    <dir-in-path>/uriel/lang/compat.sls
or  <dir-in-path>/uriel/lang.sls
or  <dir-in-path>/uriel.sls

v0.97 is also expected to allow

    <dir-in-path>/uriel/lang/compat.larceny.sls

but we do not intend to support any further
extensions in this direction until there is
a more coherent standard.

> Other implementation do this,
> what do you think?

I have been an outspoken critic of the R6RS's
failure to specify *any* portable means by which
R6RS programs can add their own libraries to
those documented within the R6RS documents
themselves.  My criticisms fell on deaf ears,
and the predicted portability problems have
come to pass.

All extensions you described are completely
implementation-dependent.  We are willing to
cooperate with other implementors to help solve
this vexing problem, but we are not willing to
implement all of the mappings that have already
been invented or will be invented in the future.
This issue needs urgent resolution by a SRFI or
some other standard that can extend or supersede
the R6RS.

When such a standard exists, Larceny will almost
certainly implement it.  In the meantime, Larceny
already supports the most widely supported mapping
from library names to file names, but even that
mapping is not supported by all implementations of
the R6RS.  At this time, there is no portable
solution to the problem, and nothing we could do
to Larceny would create a portable solution.

Will