On Tue, 5 Jan 1999, Dave Mason wrote:

> >>>>> On Tue, 5 Jan 1999 13:40:02 -0600 (CST), Donovan Kolbly <xxxxxx@rscheme.org> said:
>
> > Is it permissible for an implementation to make available the
> > definitions implied by a SRFI only within the body of a
> > corresponding `if-implements'?
>
> Not as it's currently (intended to be) written.  The problem as we
> envisioned it is that there may be alternative/conflicting SRFI's (and
> the editors will have a comment on some issues relating to this
> shortly).  So a programmer wanting to provide a foo function might say
> something like:
>
> 	(if-implements SRFI-22
> 	   (define foo ....using.some.feature.from.SRFI-22...)
> 	   (if-implements SRFI-17
> 	      (define foo ....using.some.feature.from.SRFI-17...)
> 	      (define foo ....some.portable.way...)))
>
> Would this be possible with your proposed implementation?  I assume
> the answer is yes, so it might resolve some of the other problems I
> have with SRFI-0 as it stands.

Yes, and that's exactly how I am thinking it would be used.  In general, I
imagine an application developer encapsulating their non-standard or
low-level functionality into a set of procedures for which they can
provide various "adapter" implementations based on which SRFI(s) are
available.

In my "with-module" implementation of if-implements, the local definitions
(within the if-implements) can see the SRFI-specific variables, but the
rest of the application doesn't and shouldn't -- the rest of the app
should see only the definitions that the app developer provides.

>
> More problematically, how would you implement this portably, in say,
> R5RS macros?

Well, R5RS doesn't have much module support, so I'm not sure it'd be
possible.

>
> Without your restriction, an implementation could (almost) do this
> with the code from SRFI-0:
>
> (define-syntax if-implements
>   (syntax-rules (SRFI-1 SRFI-5)
>     ((if-implements SRFI-1 yes)
>         (begin ...all.the.code.from.SRFI-1... yes))
>     ((if-implements SRFI-1 yes no)
>         (begin ...all.the.code.from.SRFI-1... yes))
>     ...)
>
> But with your restriction, the ...all.the.code... part needs to
> provide definitions in a scope that only includes the ``yes'' code,
> but defines in the ``yes'' code must be publicly visible.  This may be
> problematic for other implementations.

Good point.  Modulo syntax definitions, one would need a generalization of
something like:

  ...
  ((if-implements SRFI-1 (define (name arg ...) body ...))
   (define name
    (letrec (...tweaked defns from SRFI-1...)
     (lambda (arg ...)
       body ...))))
  ...

the main trick just being to destructure any definitions inside the `yes'
part and insert the SRFI-1 defns as a letrec in the middle.

Sadly not possible in general, I don't think, and anyway syntax
definitions wouldn't work because they're not first-class and can't
percolate up past the letrec.

I would be quite happy if the SRFI-0 spec _ALLOWED_ my approach, basically
by ambiguating on whether the definitions from the named SRFI area
available to code other than the `yes' code.  My implementation approach
would say no, they're not available, wheras other implementations which
incorporate all available SRFIs into the top-level would say yes.

Clearly, there would still be lots of room for a program to depend on one
approach or the other, but we could say that such a program was not SRFI-0
compatible anyway.

>
> > 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 like these properties!

And if I can write the right web agent, I'll build 'em automatically by
default from the posted sample implementation!  (And if we had test suites
in the same vein, I'd run those too automatically.)

-- Donovan Kolbly                    (  RScheme Development Group
                                     (  xxxxxx@rscheme.org
				     (  http://www.rscheme.org/~donovan/