On 11/24/2012 07:07 PM, John Cowan wrote:
> Per Bothner scripsit:
>
>> The question is: Do we want there to be a default implementation of
>> ($quasi-value-transformer$:foo ...) as (foo ...)?
>
> And what is the default implementation of (foo ...)?

Error.

> We seem
> to be on an infinite regress, and I'd rather just stop at
> $quasi-value-transformer$:foo.  And start there too.

Handly an infinite regress.  But I agree the extra complication
of defining a default "fall-back" implementation of
$quasi-value-transformer$:foo seems marginal.  I think it may
make sense to define one or more library functions to massage
the arguments - for example concatenating the components
of the literal part.  These would be to make it combine the
argument list - or example combining the literal part to a
single string-valued expression.

> I propose this:
>
> (1') The reader returns ($quasi-value-transformer$:foo ...).  If it
> was called from `read`, that's what the program gets.  If it was called
> from a compiler or interpreter, it applies its normal rules to determine
> if $quasi-value-transformer$:foo is bound, and if not, takes its normal
> error recovery action, whatever that is.

That seems reasonable.

What do you think of ($construct$:foo ..) instead of the rather
ungainly ($quasi-value-transformer$:foo ...)?

> It is indeed, and (1') has the same advantage.
>
>> An implementation can then *optionally* provide a default
>> implementation and/or a mechanism to override the default.
>
> By the same token, a compiler or interpreter can have some default
> mechanism that recognizes symbols of this type and provides them with
> some default value or behavior.

Kawa has a few of these. For example CLASSNAME? becomes an instance test,
and NNNUNIT (e.g. 2.5cm) becomes a "quantity" (number-with-unit).
An implementation could have some fallback-mechnanism for $construct$:foo,
but I agree it doesn't seem worthwhile trying to standardize it.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/