[Snow-users-list] srfi1 cross-contamination with srfi13

Julian Graham joolean at gmail.com
Tue Oct 9 23:32:46 EDT 2007

Hi Schemers,

Just noticed that when you 'require:' both srfi1/v2 and srfi13/v1 you
get the following error in MzScheme:

  procedure optional: expects 3 arguments, given 2: () #<primitive:equal?>

This is because the implementation of srfi1 expects the definition in
srfi1.scm, which takes two arguments but which is clobbered by the
definition in srfi13.scm, which takes three.  This seems to me to be
an issue with the scope of Snow module definitions.

My inclination is that the only thing visible outside of a particular
snowball should be the names in the 'provides:' section of the package
definition.  I don't know what the most portable way to enforce this
is, though.  One thing that'd be efficient would be to have Snow
generate interpreter-specific module definitions based on the package*
form -- in Guile, e.g.,

(package* srfi1/v2.0.1
 (provide: ... ))

...would be isomorphic to something like (define-module (srfi1 srfi1)
#:export ...). Unfortunately, each Scheme system has its own module
syntax and scoping rules -- for example, Guile doesn't require, like
PLT and other Schemes do, that you include all the definitions for
your export within the module declaration form itself; rather, it
treats (I think) the contents of the file containing the module
definition and files loaded from that file as local to that module.
So this approach might be best left to custom, interpreter-specific
Snow implementations.

An alternative might be to just encourage snowball maintainers to
limit the scope of the functions that don't get exported to within the
definitions of the ones that do -- e.g., (define (foo x) (define (bar
x) (+ x 1)) (bar x)).  This is a bit of a pain, though.

Are there any other ways to limit the scope of non-exports?


More information about the Snow-users-list mailing list