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.
Sorry for the long wait but only now am I catching up on the mail
concerning SRFI-0. Here goes:
Per Bothner <bothner@xxxxxxxxxx> noted the analogy between the
if-implements form and C's #ifdef and #if preprocessor directives, and
suggested that if-implements be generalized to permit either:
1) and, or and not combinations such as (if-implements (and SRFI-3 SRFI-5) A B)
or even
2) a Scheme side-effect free expression as the if-implements predicate
which would be evaluated at macro expansion time (in a special
compile-time namespace).
The first part of this proposal adds no power, just convenience for
the user. This convenience could also be provided by a macro (defined
in another SRFI?) which expands into if-implements forms. I don't
actually see much of a need for it (except for "not" but please supply
compelling examples to convince me otherwise) and I don't like
overloading "and", "or" and "not".
The second part of this proposal is too hairy for my taste. How do
you define precisely the sublanguage of Scheme which constitutes
"side-effect free" expressions? Can you use set! on local variables?
eq?? delay? call-with-current-continuation? exceptions? Before you
know it you have to be so restrictive that you are left with a
crippled, probably ill-defined, unappealing sublanguage that needs its
own interpreter. Also for this to work:
(if-implements (and SRFI-123 (= foo-version 200)) work-around)
this sublanguage must treat unbound variables (such as the SRFI-123)
specially so that they evaluate to #f. Yuck!
Let me repeat myself... it is important that the if-implements form
have a clear, unambiguous semantics. This will allow all of us to
build on top of it instead of around it. Also I think the
if-implements form should be easy to implement so that it doesn't add
much to the interpreter's or compiler's size (I'm thinking of an
interpreter/compiler which checks the syntax of the if-implements form
and reports appropriate error messages...).
Dave, Mike, and Shriram (The SRFI Editors) have come up with a counter
proposal which allows the program to request that a specific feature
be available and allows the program to test that a feature is
available (using COND-IMPLEMENTS a multiway if-implements). The feature
requested can affect the reader's syntax (IMPORT-READER-SYNTAX) and/or
the macro syntax and environment bindings (IMPORT-IMPLEMENTATION).
Three forms are proposed:
(COND-IMPLEMENTS (<feature-test> <body>)... (ELSE <body>))
(IMPORT-IMPLEMENTATION <feature-id>)
(IMPORT-READER-SYNTAX <feature-id>)
where <feature-test> is a <feature-id> or a combination with "and",
"or", "not". COND-IMPLEMENTS is *not* analogous to COND because it
can choose any of the clauses for which a <feature-test> checks out.
I just don't see how this non-determinism can actually be helpful in
real programs. There is not even the guarantee that identical
COND-IMPLEMENTS expressions will take the same branch. Please provide
some convincing examples... Apart from this peculiarity the
COND-IMPLEMENTS form could be built on top of the if-implements form
as a macro.
An important question for the IMPORT-IMPLEMENTATION and
IMPORT-READER-SYNTAX forms is their "execution time" with respect to
the test performed by the COND-IMPLEMENTS form. Consider:
(COND-IMPLEMENTS (SRFI-123 foo))
(IMPORT-IMPLEMENTATION SRFI-123)
For this to work, the interpreter/compiler must process the
IMPORT-IMPLEMENTATION form before the COND-IMPLEMENTS form. Because
IMPORT-IMPLEMENTATION can only appear at toplevel this apparently can
be done easily in a processing phase that is between "reading" and
"macro-expansion" which just checks toplevel forms. But what is
really meant by "toplevel"... which of these would be OK if found at
toplevel (sic!):
1) (begin (define x 1) (IMPORT-IMPLEMENTATION SRFI-100))
2) (include "foo.scm") ; if "foo.scm" contains (IMPORT-IMPLEMENTATION SRFI-100)
3) (my-import SRFI-100) ; if my-import is a macro that expands to an
; IMPORT-IMPLEMENTATION form.
4) (COND-IMPLEMENTS (SRFI-200 (IMPORT-IMPLEMENTATION SRFI-100)))
The problem is that all of these require that macro-expansion be done
*before* IMPORT-IMPLEMENTATION forms can be processed. So either
these uses of IMPORT-IMPLEMENTATION are disallowed (which I find to be
inelegant) or an iterative process, similar to one for finding
fixpoints, is used (which I find to be difficult to specify and
implement).
Moreover what happens if there are two *separately* compiled files and
one contains an (IMPORT-IMPLEMENTATION SRFI-100) and the other a
(COND-IMPLEMENTS (SRFI-100 foo))... Either
1) the "compiler" basically does nothing... it reads the source and
delays macro-expansion, code-generation, etc to link time (where a
"real" global compilation is done), the advantage here is that
the COND-IMPLEMENTS tests are globally consistent.
2) the COND-IMPLEMENTS tests are only consistent on a file by file
basis, which is not very elegant.
The IMPORT-READER-SYNTAX has similar binding-time problems, and
additionally some systems already treat the first datum of a file
specially. For example, for Gambit-C, if the first datum of a file is
the "script object" #! (as in: #! /usr/local/bin/gambit) then the file
is treated as a Scheme script (the first line is ignored and the
command line arguments visible to the script are computed specially
from the command line arguments).
The question I ask is why should all of this be in SRFI-0? Why not
leave it to some other SRFI, so that SRFI-0 can be lean and simple.
In particular, I see lots of overlap in functionality between
IMPORT-IMPLEMENTATION/IMPORT-READER-SYNTAX and a module system, so its
probably best to work on a general module system SRFI than on the
relatively crippled IMPORT-IMPLEMENTATION/IMPORT-READER-SYNTAX.
Marc