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 have uploaded the updated srfi-96.html to: http://swiss.csail.mit.edu/~jaffer/srfi/srfi-96.html | From: William D Clinger <will@xxxxxxxxxxx> | Date: Tue, 27 Nov 2007 11:39:34 -0500 | | 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. Thanks for your responses. | 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 The @copying command has been in Texinfo as least as early as Texinfo-4.7 (released in April 2004). I suspect your system has an older version of Texinfo. | % 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 Use a "prefix=" argument to "make" in order to override SLIB's default of /usr/local: make prefix=/home/will/ install | -------- | | 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*. The only occurence of *load-pathname* in SLIB which is found by: grep -n -e '[*]load-pathname[*]' *.scm is in "Template.scm" -- which is a template for *.init files. "Template.scm" is never run. I changed *load-pathname* to *foo-load-pathname* in "gambit.init". With "gambit.init" so modified, gsi was able to load JACAL (which uses SLIB) successfully. What is your basis for asserting that the internal variable must be 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: The reference to macro:load was a typo -- it should have been defmacro:load. Corrected in the new srfi-96 upload. | -------- | % 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. I have added `R5RS Macros' sections detailing the operations macro:expand, macro:eval, and macro:load. [Rationale] R5RS Macros If the macro feature is provided, then the procedures macro:expand, macro:eval, and macro:load must be defined. Of these, only macro:load is used (for loading packages) by SLIB code. macro:eval would typically be used with the repl:top-level procedure in the repl package to create a macro-enabled read-eval-print loop. macro:expand is indispensable for debugging R5RS Macros; but implementations are not required to make it functional, in which case macro:expand will always return #f. [Specification] R5RS Macros If the macro feature is provided, then the procedures macro:expand, macro:eval, and macro:load will be defined. Function: macro:expand sexpression Takes an expression, macro-expands it, and returns the result of the macro expansion. If an implementation does not support macro:expand, then #f is returned. Function: macro:eval sexpression Takes an expression, macro-expands it, evals the result of the macro expansion, and returns the result of the evaluation. Procedure: macro:load filename filename should be a string. If filename names an existing file, the macro:load procedure reads Scheme source code expressions and definitions from the file and evaluates them sequentially. These source code expressions and definitions may contain macro definitions. The macro:load procedure does not affect the values returned by current-input-port and current-output-port. | 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". Program-arguments was insufficiently specified; I have added text to both SLIB (http://swiss.csail.mit.edu/~jaffer/slib_7.html#SEC267) and SRFI-96: If (provided? 'program-arguments): Function: program-arguments Returns a list of strings, the first of which is the program name followed by the command-line arguments. | It would probably be enough for SRFI 96 to provide a pointer to the | relevant SLIB documentation for these features. I have added the text: If a feature is provided whose name is the same as an SLIB module, then it will provide the procedures and syntax as documented for that SLIB module. | SRFI 96 does not explain the obligations incurred by an | implementation that provides its own defmacro. All implementations must implement defmacro. The obligations are gentemp, defmacro:eval, defmacro:load, defmacro?, macroexpand-1, macroexpand, and defmacro, specified in the section "Defmacro". | If the defmacro feature is listed in slib:features, then code that | uses defmacro will trigger an infinite loop in defmacro:expand*. defmacro:expand* is a part of the defmacroexpand package, not part of the defmacro feature. Several implementations have an "autoload" which brings in the defmacroexpand package the first time that defmacro:eval (calling defmacro:expand*) is called: (define base:eval slib:eval) (define (defmacro:eval x) (base:eval (defmacro:expand* x))) (define (defmacro:expand* x) (slib:require 'defmacroexpand) (apply defmacro:expand* x '())) | 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. If your macro-expand expands all the defmacros in its argument, then your definition is fine; just add the symbol defmacroexpand to slib:features. | 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. Running JACAL (http://swiss.csail.mit.edu/~jaffer/JACAL) on "test.math" is a good test case, using some DEFMACRO:LOADs and many procedure packages. | 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? UMB-Scheme included an ancient copy of SLIB, which Guile originally used only for its copy of SLIB. This arrangement violated SLIB's license and generated reports over and over for SLIB bugs which had been fixed years ago. I would rather not repeat that experience. Please don't incorporate a copy of SLIB in your distribution. If you send me "larceny.init", then I will include it in the SLIB distribution and a SRFI-96 link along with the other implementations.