This page is part of the web mail archives of SRFI 96 from before July 7th, 2015. The new archives for SRFI 96 contain all messages, not just those from before July 7th, 2015.
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