[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Monkey-patching $quasi-value$
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 ...)?
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.