Namespace management & SRFI-0
Donovan Kolbly
(05 Jan 1999 19:40 UTC)
|
Re: Namespace management & SRFI-0
Dave Mason
(05 Jan 1999 21:08 UTC)
|
Re: Namespace management & SRFI-0
Donovan Kolbly
(05 Jan 1999 21:25 UTC)
|
Re: Namespace management & SRFI-0 Marc Feeley (06 Jan 1999 17:10 UTC)
|
Re: Namespace management & SRFI-0
Donovan Kolbly
(06 Jan 1999 17:48 UTC)
|
Re: Namespace management & SRFI-0
Marc Feeley
(06 Jan 1999 19:35 UTC)
|
Re: Namespace management & SRFI-0
Donovan Kolbly
(06 Jan 1999 19:53 UTC)
|
Re: Namespace management & SRFI-0
Marc Feeley
(12 Jan 1999 22:37 UTC)
|
Re: Namespace management & SRFI-0 Marc Feeley 06 Jan 1999 17:10 UTC
> Is it permissible for an implementation to make available the definitions > implied by a SRFI only within the body of a corresponding `if-implements'? No. Remember that an SRFI just describes a property of a Scheme system which is more general than an API consisting of a set of procedures and special forms. For example an SRFI, say SRFI-123, could specify case-sensitivity (i.e. a Scheme system which conforms to SRFI-123 is case sensitive and distinguishes the symbol foo from Foo and FOO). So consider the program: (if-implements SRFI-123 (begin) (error "The Scheme system must be case sensitive to run this program!")) (define (f x) (case x ((Foo) 1) ((FOO) 2) (else 3))) (write (f 'foo)) ; we want this to print 3 So if you limit case-sensitivity to the first branch of the if-implements, this program will not work as expected. > My thinking is this: what I would like to do is map `if-implements' to > RScheme's `with-module'. ((with-module M B ...) provides access within > its body, B ..., to the exported definitions of the given module M.) I am > planning on providing most SRFI implementations in the form of loadable > modules with canonical names. This should allow users to easily download > new SRFI implementations, and propertly manage the namespace even of > conflicting SRFIs. I think a different mechanism is needed for this which does dynamic-loading of required modules, etc. That's for a different SRFI to propose. SRFI-0 should only be viewed as a macro-expansion-time feature tester. Marc