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

Re: SRFI 10

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

Per Bothner scripsit:

> Two complications: For good and ill, SRFI 10 creates the object at
> read time, which means it can be returned by the read procedure.

That's true.  But as it says at the end of the SRFI 10 "Specification"

    This SRFI does not specify how the Scheme reader interprets a
    specific <hash-comma-datum> and creates the corresponding Scheme
    value. This is left to particular SRFIs. The behavior of the
    reader when it fails to interpret a #,() form is also unspecified.

In particular, I am proposing that in an implementation that supports
SRFI 108, the objects created by SRFI 10 syntax are lists whose car
is `$quasi-value$` (or whatever, depending on other mail threads).
This is a formally correct and very useful object to create.  There is
no requirement for SRFI 10 to create a "final" object.

> So one possibility is that *if* $quasi-value-transformer$:foo exists
> in the read-type dynamic environment, is bound to the function,

I think it is a serious mistake to compromise layering in this way.  This
lexical syntax, like that of SRFI 107, or for that matter the standard
quote, backquote, comma, and comma-at, should desugar to a corresponding
S-expression without regard to whether the names it introduces are defined
anywhere or by anybody.  In particular, when a compiled program calls
(read) it should be able to process these things without regard to what
names were defined in the program before it was compiled.

> *and* all the arguments are literal (i.e. self-evaluating objects,
> or (quote xxx) forms), 

The arguments need not be self-evaluating, because the "Implementation"
section of SRFI 10 makes it clear that they are passed to the transformer
as if by `apply`, that is, unevaluated.

> I'm nervous about this as the default.  One problem is that the
> reader can't know (easily) if an overriding different mapping for
> $quasi-value-transformer$:foo will be defined at expansion time,
> perhaps by importing a library.

As I say, I think it need not and in fact should not know.  If the
appropriate name is not defined, the interpreter or compiler can complain
in the usual way, just as if you used `'foo` in a scope where `quote`
is not defined.  (Such scopes don't normally occur, of course).

John Cowan    cowan@xxxxxxxx    http://ccil.org/~cowan
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature.  --The Catholic Encyclopedia, s.v. "telepathy" (1913)