Yes... quasiquoting in Perl 5 is currently crudely emulated
by feeding things to PPI::Tokenizer and PPI::Transform. :-)
> I was wondering how that would work. Many languages use unusual
> syntax for quasiquoting and code splicing but Perl 6 is already
> nibbling into unicode.
> Does that mean macros will be grafting and pruning the AST that
> comes back from a quote/rule?
That is my current understanding; you'll have to explicitly call
parse and compile and then eval.
> Or will there be syntatic shorthand?
There's no shorthand for the process as far as I'm aware. I'd love
to see a sane design, and implementors are welcome too. :)
Thanks,
/Autrijus/
You're doing what now? :)
Just in case this ever comes up again, let me clear something up now.
It's worth noting it once here for everyone.
PPI is not a code parser. By code parser I mean taking a string and
turning it into working code. PPI is a document parser. It parses ONLY
on syntax to form a model of a document. Any conclusions it might make
on the structure of the resulting code are secondary.
It cannot determine implicit parameters for function calls, which also
means it has difficulty or cannot determine operator precedence.
It is theoretically impossible to (document) parse Perl "fully" without
also executing it, and even then perl doesn't (document) parse Perl, it
just (code) parses Perl, or rather runs Perl.
So to summarise, PPI is of limited use when it comes to working with
bytecode or something that will be executed. It is for working with
documents, not code.
And I'm done here :)
Adam K
Right. Hence it guarantees at most well-formness, instead of semantic
correctness. Hence, "crudely emulated", because we don't have anything
better at this moment.
> So to summarise, PPI is of limited use when it comes to working with
> bytecode or something that will be executed. It is for working with
> documents, not code.
Yup. But PPI is still much better than consuming and concatenating
raw strings. :-)
Thanks,
/Autrijus/