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

question about Quasiquote

Sorry for this question since it might appear stupid.  I never managed
to understand the reasons for the way quasiquote is defined.  What I
mean are the nesting levels.  Could someone give a rationale for them,
please?  Are there any historical or other reasons for the current

Here is how I understand what quasiquote should do:

	- give a way to define an ARBITRARY template where certain parts
	  are to be filled in at runtime
	- those parts are determined by evaluating certain ``marked''
	  sub-expressions (-> unquote, -> unquote-splicing)

I understand that there is this inevitable difficulty with having
unquote or unquote-splicing as (constant) part of the template.  (The
same difficulty in a differeny guise arises in the high-level macro
system with ...)

Using the current solution it is very hard to achieve the following
behavior, for instance:

	(define a 'aa)
	(define b 'bb)

	`<some template> => `(aa bb)

where aa and bb in the result are the value of a and b respectively.
Intuitively I would write:

	``(,a ,b)

but this doesn't work, because the ``unquoted'' subexpressions are not
at the same nesting level as the outermost quasiquote.

I really couldn't come up with any sensible way to make use of the
nesting level solution.  It seems that it is meant for a framework
where multiple evaluation can occur.  So far we didn't even have eval
in the language!  And even if we had -- I don't see any problem the
solution of which might benefit.

Last, but not least, I want to give an alternative rule for defining
the semantics of quasiquote.  Proposal:

``Inside a quasiquote exactly those unquote- and unquote-splicing-
subexpressions will be replaced (in the usual way) which do not
contain any further unquotations.''

This rule does not allow quasiquote itself to be used in an
unquotation.  This, however, doesn't seem to be a big loss.  (Well, I
see that there is a problem when using quasiquote in macros.  Maybe I
need to think about it a bit more...)  There is also a small
inconvenience with unquotations that are meant to be constant and
which do not contain further unquotations.  The situation looks like:

	``(,a ,b)

which we might want to evaluate to

	`(,a bb)

There is a somewhat clutchy, but nevertheless quite simple solution:

	``(,,'a ,b) => `(,a bb)


I don't like the current definition of quasiquote's semantics.  I
think it is not general enough and I cannot see any use of the (very
complicated) nesting level business.  I showed that there are ways to
define quasiquote's semantics in a way that is intuitively clearer,
less restrictive, and in most real cases equivalent to the current
solution.  I need to think a bit more about the interaction with


PS:  R4RS places quasiquote in the ``derived expression types'' section.
     The claim is that it can be rewritten using cons, list, vector, append
     and so forth.  I oppose this point of view because I think that
     redefining any of these procedures must not change the behavior of