I implemented SRFI 96 for Larceny on a Solaris machine,
thinking this fresh implementation would be a good test
of the SRFI 96 specification.  It was.

I downloaded slib3a5.zip and unzipped it into a
directory named lib/SLIB relative to Larceny's root
directory.  My attempt to install SLIB using gnu make
resulted in these errors:

--------
% make infoz
makeinfo slib.texi --no-warn --no-split -o slib.info
slib.texi:14: Unknown command `copying'.
slib.texi:32: Unmatched `@end'.
slib.texi:62: Unknown command `insertcopying'.
makeinfo: Removing output file `slib.info' due to errors; use --force to preserve.
make: *** [slib3a5.info] Error 2

% make install
test -d /usr/local/man/ || mkdir /usr/local/man/
mkdir: cannot make directory `/usr/local/man/': No such file or directory
make: *** [pinstall] Error 1
--------

Giving up on the Makefile, I proceeded as instructed
by the README:

% larceny -path lib/SRFI/SLIB
> (require 'srfi-96)
> (require 'new-catalog)

That worked well enough to begin testing, which soon
proved that the SRFI 96 specification of some things
is insufficiently detailed.

The specification of with-load-pathname refers to "an
internal variable" as though the name of that variable
were insignificant.  In reality, SLIB (as distributed)
won't work unless that internal variable is a global
variable named *load-pathname*.

SRFI 96 refers to macro:load but does not specify it
and does not indicate that an implementation of SRFI 96
must define it.  Apparently SLIB doesn't define it either:

--------
% larceny -path lib/SRFI/SLIB
Larceny v0.951 "First Safety" (Nov 11 2007 09:34:53, precise:SunOS5:split)

> (require 'srfi-96)
#t

> (require 'new-catalog)

> (require 'define-record-type)

Error: Undefined global variable "macro:load".
Entering debugger; type "?" for help.
debug> a
--------

Adding definitions of macro:eval and macro:load to the
implementation of SRFI 96 fixed that problem.

The SRFI 96 specification of slib:features does not
adequately describe the semantics of most features.
In particular, it does not specify what each feature
obliges an implementor to provide.  For example, the
specification of program-arguments doesn't say whether
the first element of the list should be the name of
the command, e.g. "larceny".  It would probably be
enough for SRFI 96 to provide a pointer to the relevant
SLIB documentation for these features.

SRFI 96 does not explain the obligations incurred by an
implementation that provides its own defmacro.  If the
defmacro feature is listed in slib:features, then code
that uses defmacro will trigger an infinite loop in
defmacro:expand*.  I got rid of this loop by defining
defmacro:expand* as follows, where macro-expand is
Larceny's native macro-expander:

    (define (defmacro:expand* x)
      (macro-expand x))

I doubt whether that definition is fully compatible with
SLIB, however.

My implementation of SRFI 96 now appears to be working,
but it's hard to tell how well it's working because I
don't have a test suite for SLIB.

Question:  Should SLIB be distributed with Larceny, or
would it be better to provide SRFI 96 alone and to tell
users of Larceny how to obtain and to install the latest
version of SLIB themselves?

Will