I see you're trying to support quasi-quoting and regular quoting in the same construct: the "quoted expression".
I'm afraid that this will fail; sufficiently complex situations involving nested quasi-quotes will force you to confront the reality that you need separate quote and quasi-quote expressions.
The essence of the matter is that if quote is also quasiquote, you have ambiguities like:
'(a b c '(,d))
The machine has to decide that the comma belongs to one of the two quotes. That decision could sometimes be opposite to programmer intent. Which of these did the programmer really mean?
`(a b c '(,d))
'(a b c `(,d))
Or using Awl syntax, suppose d contains 42:
{a b c {\d}}
When we evaluate this, is the d interpolated in the current evaluation round so that the result is
{a b c {42}}
Or is it protected from evaluation so that the result is
{a b c {\d}}
The issue isn't which one is right, but not being able to express either choice.
You might think that a viable strategy for awl Awl would be to always associate (uncompounded) unquotes with the inner-most Q-expr, and when the programmer wants that to belong to an outer Q-expr, the programmer can instead use embedded S-exprs as "true" quotes, like this:
{a b c {\d}} -> {a b c {\d}}
{a b c (\d)} -> {a b c (42)}
But then what if I want neither of the above results, but actually this object:
{a b c {42}}
I.e. I want the outer quasiquote to write the inner one.
I tried, in a Lisp dialect, unifying quotes and quasiquotes and was ultimately forced to confront the reality that it cannot work, and painfully backed out of the change. It was okay for very simple uses, but the crippled expressivity spoiled the quasiquote for serious macro programming.
1 comment
[ 3.1 ms ] story [ 12.8 ms ] threadI'm afraid that this will fail; sufficiently complex situations involving nested quasi-quotes will force you to confront the reality that you need separate quote and quasi-quote expressions.
The essence of the matter is that if quote is also quasiquote, you have ambiguities like:
The machine has to decide that the comma belongs to one of the two quotes. That decision could sometimes be opposite to programmer intent. Which of these did the programmer really mean? Or using Awl syntax, suppose d contains 42: When we evaluate this, is the d interpolated in the current evaluation round so that the result is Or is it protected from evaluation so that the result is The issue isn't which one is right, but not being able to express either choice.You might think that a viable strategy for awl Awl would be to always associate (uncompounded) unquotes with the inner-most Q-expr, and when the programmer wants that to belong to an outer Q-expr, the programmer can instead use embedded S-exprs as "true" quotes, like this:
But then what if I want neither of the above results, but actually this object: I.e. I want the outer quasiquote to write the inner one.I tried, in a Lisp dialect, unifying quotes and quasiquotes and was ultimately forced to confront the reality that it cannot work, and painfully backed out of the change. It was okay for very simple uses, but the crippled expressivity spoiled the quasiquote for serious macro programming.