[Larceny-users] library name clashes in larceny with the -r7rs -program options

[John Bignucolo]

Greetings,

As an exercise, I tried to use the '-r7rs' and '-program' options to
larceny to implement something really simple: a Scheme version of echo. Eg,

​
$ time larceny -r7rs -program echo.sps -- a b c
a b c

real 0m1.083s
user 0m1.064s
sys 0m0.012s

​This was with Larceny v0.99 "Goldie" (May 25 2016 01:16:34,
precise:Linux:unified)
larceny.heap, built on Wed May 25 01:17:00 EDT 2016

I
​ ran into a problem when I tried to change the program to use the
string-join function from SRFI-13.

The '-r7rs' '-program' options require that you import everything you need.
Since string-join is part of SRFI-13 I thought all I needed to do was:

(import (scheme base)
(scheme load)
(scheme write)
(scheme process-context)
(srfi 13))

;; skip over 'larceny' as arg0
(let ((prog-args (cdr (command-line))))
(if (not (null? prog-args))
(display (string-join prog-args))))
(newline)

But this generated an error:

Syntax violation: import

Different bindings for identifier imported from libraries () and (srfi :13
strings)

Form: string-for-each

Trace:

Error: unhandled condition:
Compound condition has these components:
#<record &who>
who : import
#<record &message>
message : "Different bindings for identifier imported from libraries ()
and (srfi :13 strings)"
#<record &syntax>
form : string-for-each
subform : #f

Entering debugger; type "?" for help.

I was able to able to get it work by changing the srfi import definition to
be:

(only (srfi 13) string-join)

But this resulted in a five-fold increase in runtime, due I assume, to a
longer startup time required to find string-join:

$ time larceny -r7rs -program echo.sps -- a b c
a b c

real 0m5.036s
user 0m5.008s
sys 0m0.020s

Was I wrong in using (srfi 13) in the import list?

What is the correct method for importing SRFI-13 (or other libraries) that
have names that clash with those defined in (scheme base)?

Regards,
John

[William D Clinger]

I ran into a problem when I tried to change the program to use the
string-join function from SRFI-13.
The '-r7rs' '-program' options require that you import everything you need.
(import (scheme base)
(scheme load)
(scheme write)
(scheme process-context)
(srfi 13))
Syntax violation: import
Different bindings for identifier imported from libraries () and (srfi :13
strings)
Form: string-for-each

A lot of the SRFI specifications are incompatible with R7RS
libraries or R6RS libraries or other SRFI libraries. You have
to resolve those conflicts on your own, because Larceny can't
just guess which definition you want.

In this case, the specs for string-map and string-for-each
in SRFI 13 are incompatible with their R7RS specifications.
There are various ways to resolve that. If you don't need
string-map and string-for-each, or you are willing to work
with the R7RS versions of those procedures, you can write

(import (scheme base)
(except (srfi 13) string-map string-for-each))

I was able to able to get it work by changing the srfi import
(only (srfi 13) string-join)

That's another good way to resolve the conflicts, and it's
an even better way if string-join is all you need.

But this resulted in a five-fold increase in runtime, due I assume,

The longer startup time is caused by the implementation of
(srfi 13) in Larceny. The (srfi 13) library imports the
(srfi :13) library, which imports six R6RS libraries, two
other SRFI libraries, the R7RS (scheme base) library, and
the (larceny shivers-syntax) library, which defines the
macros Olin Shivers used to write his implementation of
(srfi 13). Some of those libraries may import yet other
libraries.

It just takes a while to load all those libraries.

You can examine the source code for those libraries in

lib/SRFI/srfi/13.sld
lib/SRFI/srfi/%3a13.sls

(et cetera)

Will

[John Bignucolo]

Thanks Will.

Since it's release in July 2013, I had assumed (hoped?) that the authors of
the SRFI libraries would have updated their implementations to play nicely
with R7RS. But it's a big job to maintain compatibility between R5RS, R6RS
and R7RS so it's no surprise that there are inconsistencies.

Thanks for the clear explanation of the way names are resolved and
libraries imported.

Regards,
John

Post by William D Clinger

I ran into a problem when I tried to change the program to use the
string-join function from SRFI-13.
The '-r7rs' '-program' options require that you import everything you

need.

(import (scheme base)
(scheme load)
(scheme write)
(scheme process-context)
(srfi 13))
Syntax violation: import
Different bindings for identifier imported from libraries () and (srfi

:13

strings)
Form: string-for-each

A lot of the SRFI specifications are incompatible with R7RS
libraries or R6RS libraries or other SRFI libraries. You have
to resolve those conflicts on your own, because Larceny can't
just guess which definition you want.
In this case, the specs for string-map and string-for-each
in SRFI 13 are incompatible with their R7RS specifications.
There are various ways to resolve that. If you don't need
string-map and string-for-each, or you are willing to work
with the R7RS versions of those procedures, you can write
(import (scheme base)
(except (srfi 13) string-map string-for-each))

I was able to able to get it work by changing the srfi import
(only (srfi 13) string-join)

That's another good way to resolve the conflicts, and it's
an even better way if string-join is all you need.

But this resulted in a five-fold increase in runtime, due I assume,

The longer startup time is caused by the implementation of
(srfi 13) in Larceny. The (srfi 13) library imports the
(srfi :13) library, which imports six R6RS libraries, two
other SRFI libraries, the R7RS (scheme base) library, and
the (larceny shivers-syntax) library, which defines the
macros Olin Shivers used to write his implementation of
(srfi 13). Some of those libraries may import yet other
libraries.
It just takes a while to load all those libraries.
You can examine the source code for those libraries in
lib/SRFI/srfi/13.sld
lib/SRFI/srfi/%3a13.sls
(et cetera)
Will