I maintain Camlp5, and was sitting next to DDR when he was writing Chamau original name of Camlp4], back in the day. So I have some familiarity with the roots of all this.
- All these quotations systems have their roots in LISP’s quotations and quasiquotations, just so as @Gopiandcode describes.
- I’m getting old (so the memories are fading) but IIRC the immediate ancestor was the quotation mechanism in the original LF ML, wherein a string enclosed in backticks (don’t know how to write it in Markdown, so not gonna try) was parsed using a special “term” parser.
- Daniel generalized this idea to arbitrary quotations, where quotations were named, and the syntax:
<:argle< .... text .... not containing gtgt ... >>
meant “invoke the quotation expander named ‘argle’ on this text”. And then (again IIRC) he took inspiration from antiquotations in LISP/Scheme[1] to add back in antiquotations, e.g.
<:expr< $a$ + $b$ >>
- In any case, you are right, that in some deep sense, SWI-Prolog’s quasiquotes are probably equipotent to Camlp5’s. Indeed, one could imagine using the new PPX string-extension syntax, viz.
{%argle| ......|} (and {argle bar| ..... string not containing bar |bar} ) instead of <:argle< ..... >> and then one could imagine recursively-embedded quotations-within-quotations. And this wouldn’t even be too cumbersome, textually.
A key thing that makes parsing these quotations tractable, is that you can find the end of the quotation without parsing its contents – just look for “>>”. And this is the same for the string-extensions. And when parsing the contents of a quotation, when you find a “$”, you just scan forward for the next “$” – that’s where the antiquotation ends.
Key point being, you don’t have to parse the contents of either quotation or antiquotation, in order to know where it ends.
- But then the problem is how to embed anti-quotations within those quotations, without making things hopelessly cumbersome. What I mean is, imagine a quotation like
<:expr< $a$ + $b$ >>
which would be (in string-extension notation)
{%expr| $a$ + $b$ |}
and now imagine replacing the “a” with an expression like
let e0 = <:expr< x * x >> in <:expr< $e0$ * $e0$ >>
again, written using string-extension notation:
let e0 = {%expr| x * x |} in {%expr| $e0$ * $e0$ |}
Now combine those two bits of string-extension-laden text – you get something that’s both difficult-to-parse and difficult to even read.
I hope this is intelligible. The upshot of what I’m trying to say is that a quotation-that-contains-an-antiquotation-that-itself-contains-a-quotation-that-again-contains-an-antiquotation makes parsing pretty damn difficult.
[1] But I have a vague memory that Caml-Heavy (the original Caml on top of LeLisp) supported antiquotations, and maybe Daniel got his inspiration for that – it’s all a haze now.
ETA: the more I think about it, the more I am convinced that Daniel got a lot of his inspiration from Caml-Heavy’s quotations. I just don’t have any pointer to where I could find examples of that: it’s just a “feeling” based on vague and hazy memories. Sorry.
