[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Namespace management & SRFI-0

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 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.

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

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.

> 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!