Using Quasiquotations at run time

[EricGT]

Quasiquoations are almost always converted at compile time. However there are some times when being able to convert a quasiquotation at run time is useful.

This test case shows how.

SWI-Prolog/swipl-devel/blob/d7eb4d249d95a425db8837868dcc189e3e5f166b/src/Tests/core/test_qq.pl#L55-L58

[ridgeworks]

Currently this is what is required and what I was trying to get at with this thread:

Quasi-quotation API extension?

I have to admit I don’t fully understand all the ramifications of quasi-quotations, but: The API for quasi-quotations does not obviously allow for the content to be a normal string. Instead it seems to be some opaque term created by the builtin parser. Would it be possible/desirable to extend this API so either the content could be a string, or to support a predicate to convert a normal string to such an opaque term? In essence, is there a way to decouple the builtin Prolog parser from the ind…

The reason for this is that the QQ content is at the Prolog level is an opaque term containing a pointer to memory. It would be nice to have a runtime API that didn’t require you to construct a string in qq format and then run it back through the parser which is somewhat wasteful.

One possibility is to define an additional multifile QQ API predicate, e.g.,

qq_parse(+Syntax,+String,+VariableNames,-Result).

Note that this doesn’t require any changes to the current implementation; it just standardizes a way for QQ implementations to support runtime evaluation if they so choose.