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

Re: What #,(foo) does tell, and what it does not

This page is part of the web mail archives of SRFI 10 from before July 7th, 2015. The new archives for SRFI 10 contain all messages, not just those from before July 7th, 2015.

   Date: Wed, 6 Oct 1999 16:56:47 -0400
   From: Marc Feeley <feeley@xxxxxxxxxxxxxxxx>
   References:  <199910061900.TAA27600@xxxxxxxxxxxxxx>

   > Now consider
   >         (cond-expand
   >          ((and srfi-4 srfi-10 srfi-10-4)
   >           (define sample-vector '#,(f32 1.0 2.0 3.0))))

   Note that mixing "cond-expand" and "#,(...)" as in this example is not
   a good practice.  That is because "#," operates at read-time and
   cond-expand operates later, at macro-expansion time.  So the
   constructor for f32 will be executed regardless of the presence of
   srfi-4, srfi-10, and srfi-10-4 (and if "#," is not supported by the
   reader, you will get a reader error).

Any SRFI that extends Scheme's external syntax has this problem.
It can be avoided when using the configuration language in SRFI-7 by
using a `files' clause to delay reading the code until after the
feature dispatch has been done.

  (feature-cond ((and srfi-4 srfi-10 srfi-10-4)
                 (files "good-buddy.scm"))))

The file `good-buddy.scm' can then use #,(f32 ...), assuming that
is what SRFI-10-4 provides.

(This would not work in the implementation given in the SRFI-7
 document, which just uses READ to read the contents of files.
 Making it work is straightforward.)

   The "#," mechanism requires the user to understand yet another level
   of compilation and the time when it is performed (and the model is
   already not that simple if you consider forms like "(load ...)",
   "(include ...)", and "(eval ...)", and the REPL).

I am no longer at all sure that the intent of SRFI-10 is to provide
a mechanism for read-time evaluation.

One reading of SRFI-10 and the ensuing discussion is that SRFI-10
is not proposing an extension of Scheme but rather a convention for
future SRFIs (footnote 1).  What is being proposed is that the
following rule be added to the grammar for external representations
(see section 7.1.2 in R5RS):

 <compound datum>  -->  #,(<symbol> <datum>*)

and that future SRFIs that contain new read syntax for values use
this syntax with an appropriate symbol.

Seems reasonable to me, if in fact it is what SRFI-10 is about.

                                     -Richard Kelsey

Footnote 1: This would make SRFI-10 a `Scheme Request For Requests For
Implementation', or S(RF)2I in RnRS notation.