[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 ...)?


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
per@xxxxxxxxxxx   http://per.bothner.com/