[Larceny-users] finding libraries

[Marco Maggi]

I am trying to see if I can run my extensions
with Larceny, too, in addition to Ikarus and
Ypsilon. I try this by running the test suites
from a Makefile on a Unix like system.

The first problem I am having is that there is
no simple way to augment Larceny's libraries
search path. The give-me-once "-path" switch
forces me to think how to do it (so it is not
user friendly), while an environment variable
would be perfect (and akin to other Schemes).

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

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. Other implementation do this,
what do you think?

[William D Clinger]

Post by Marco Maggi
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.

Post by Marco Maggi
The second problem is that Larceny neither
supports loading a library for "(uriel lang)"
<dir-in-path>/uriel/lang/main.sls
<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.

Post by Marco Maggi
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

[Jon Wells]

Post by William D Clinger
v0.97 is also expected to allow
<dir-in-path>/uriel/lang/compat.larceny.sls

Slightly off topic but it seems to me that burying the name of an
implementation in a file name as a mechanism for locating that
implementation's version of a library is kinda less than complete.

Has there ever been any discussion of allowing import clauses to appear
anywhere other than the toplevel...

So one could...

(import (rnrs))
:
(if <some-arbitrary-condition>
(import (a guff))
(import (different guff)))
:
<refer to things exported by guff>

Or should that work & I've misunderstood the library section of r6rs
again?

jon.

[Marco Maggi]

(I am not a cat :-)

Post by William D Clinger
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.

All of this is possible, but not easy;
I do not want to learn how to hack scripts,
and hack them again after each upgrade. I
will roll my own script, but I am still
convinced that making it simple with an
env-var would be a good service to the
users.

Post by William D Clinger
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

Yes. I will experiment with this, and probably
adopt this convention.

Post by William D Clinger
v0.97 is also expected to allow
<dir-in-path>/uriel/lang/compat.larceny.sls

Fine!

[Marco Maggi]

Post by Jon Wells
Has there ever been any discussion of
allowing import clauses to appear
anywhere other than the toplevel...

I cannot speak for R6RS requests, but
Ikarus allows it in non-R6RS mode.

[William D Clinger]

Post by Jon Wells
Has there ever been any discussion of allowing import clauses to appear
anywhere other than the toplevel...

Yes, there has been some discussion. However...

Post by Jon Wells
So one could...
(import (rnrs))
(if <some-arbitrary-condition>
(import (a guff))
(import (different guff)))
<refer to things exported by guff>

That would be a bad idea for several reasons. For
one thing, the scope of the conditional imports
would be unclear; to drive that point home, consider
what happens when you import in one branch of the
conditional but not in the other. It would then be
impossible to compile the scope of the conditional
imports because the compiler wouldn't even know the
names being imported. Even if the compiler were
able to figure that out, you'd have to describe
some semantics for the case where the sets of
identifiers imported by the conditional imports
were different, and I don't think you'd be able
to come up with a reasonable semantics for that.

Hence no one has proposed conditional imports in
the form you suggested above.

Furthermore the R6RS forbids all such extensions,
presumably in an attempt to improve portability of
R6RS code. Implementations that claim to implement
the R6RS while providing such extensions would be
violating one of the "absolute requirements" of
the R6RS.

I have to admit that some of the R6RS's "absolute
requirements" are really dumb. That is part of
why no one has yet released an R6RS-conforming
implementation.

Will

[Jon Wells]

Post by William D Clinger

Post by Jon Wells
Has there ever been any discussion of allowing import clauses to appear
anywhere other than the toplevel...

That would be a bad idea for several reasons. For
one thing, the scope of the conditional imports
would be unclear; to drive that point home, consider
what happens when you import in one branch of the
conditional but not in the other. It would then be
impossible to compile the scope of the conditional
imports because the compiler wouldn't even know the
names being imported. Even if the compiler were
able to figure that out, you'd have to describe
some semantics for the case where the sets of
identifiers imported by the conditional imports
were different, and I don't think you'd be able
to come up with a reasonable semantics for that.

Yeah, I know... that's why I made the example so "simple".
Guess I'll stick with a language which implements (load ...)

jon.