[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Monkey-patching $quasi-value$

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.

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


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/