Re: when GC is permitted Marc Feeley (12 Jan 2004 03:55 UTC)
Re: when GC is permitted Marc Feeley 12 Jan 2004 03:55 UTC
Richard Kelsey wrote:
> From: firstname.lastname@example.org (Thomas Bushnell, BSG)
> Date: 11 Jan 2004 15:37:24 -0800
> This is would be the first SRFI to say "if your Scheme is too fancy,
> you can't implement this."
> Nope, that honor belongs to SRFI-0. SRFI-0 assumes that a
> Scheme implementation implements a fixed set of SRFIs that
> are all always available.
That is not true. Here is an excerpt from SRFI-0:
Moreover, in some systems a given feature may be in effect
throughout the entire program if it is in effect anywhere at all.
Other systems may have more precise mechanisms to control the
scope of a feature (this might be the case for example when a
module system is supported). In general it is thus possible that
a feature is in effect in some parts of the program and not in
> There is no sensible way to
> implement it in a system with optional modules, as are found
> in PLT and Scheme 48. This was pointed out during the
> discussion period and it was finalized anyway.
A perfectly valid view of cond-expand is that it tests if, at the
location of the cond-expand, a particular feature is available.
SRFI-0 does not say how to make features available and what their
scope is, it only says how to test for their presence. Compile-time
switches, module systems, or SRFI-7 could be used to specify which
features must be available. This decoupling of feature inclusion and
feature testing allows a module to be written in a style where it
operates correctly in different contexts (availability of one feature
or another or none).
> There may be others, but SRFI-0 is definitely the first.
But cond-expand is a portable 35 line R5RS macro. How can you say it
is difficult to implement in any reasonable Scheme system? I know
that you don't want to implement it in Scheme 48 because you disagree
with the philosophy behind it, and I respect that, but that is very
different from saying that it is technically difficult.