This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
On Tue, 5 Jan 1999, Dave Mason wrote: > >>>>> On Tue, 5 Jan 1999 13:40:02 -0600 (CST), Donovan Kolbly <donovan@xxxxxxxxxxx> 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 ( d.kolbly@xxxxxxxxxxx ( http://www.rscheme.org/~donovan/