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" section: 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)