[Snow-users-list] srfi1 cross-contamination with srfi13
Jeremie Lasalle Ratelle
pouexmachinax at gmail.com
Wed Oct 10 14:08:41 EDT 2007
Well at least the error. For now, I'll make both compatible. Maybe with a
srfi support package or just by
using the same macro for both.
On 10/9/07, Julian Graham <joolean at gmail.com> wrote:
> 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?
> Snow-users-list mailing list
> Snow-users-list at iro.umontreal.ca
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snow-users-list