SRFI 10 John Cowan (24 Nov 2012 07:34 UTC)
Re: SRFI 10 Per Bothner (24 Nov 2012 20:49 UTC)
Re: SRFI 10 John Cowan (24 Nov 2012 23:24 UTC)
Re: SRFI 10 Per Bothner (25 Nov 2012 02:23 UTC)
Re: SRFI 10 John Cowan (25 Nov 2012 02:40 UTC)

Re: SRFI 10 Per Bothner 24 Nov 2012 20:49 UTC

On 11/23/2012 11:34 PM, John Cowan wrote:
> Therefore, I would consider subsuming SRFI 10 into SRFI 108 by desugaring
> #,(foo a b "10" 32) as #&foo[&{'a 'b "10" 32}].  Note that symbols and
> lists must be quoted as well as strings in order to force them to be
> interpreted as datums.  Since this makes define-reader-ctor unnecessary,
> and it is unscoped and has phasing problems, I would leave it out.

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

So one possibility is that *if* $quasi-value-transformer$:foo exists
in the read-type dynamic environment, is bound to the function,
*and* all the arguments are literal (i.e. self-evaluating objects,
or (quote xxx) forms), then $quasi-value-transformer$:foo is
invoked at read-time.

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.

A further complication (as mentioned by Shiro Kawai in a message with
the subject "Literals vs Quasi-literals") is you get some anomalies
if the created object is not self-evaluating.

So I think read-time expansion should only be done if explicitly requested.
One idea is a parameter object whose value is an association list, mapping
tags to expansion procedures.  Read checks this parameter if the tag is
bound - if so read calls the associated procedure.

Do that seem like a good solution?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/