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