Carl Mäsak

> I would be fine with the `{{{identifier: id}}}` unquote accepting both `Q::Identifier` nodes and `Str` values. `Q::Identifier` is basically the only node type where I think this automatic coercion...

I'll just note that this issue is a little bit stalled because it's hit some conceptual difficulties. When you're about to parse an expression, you might hit a prefix op...

Nothing has happened on this front. I'm defaulting to suggesting `qtype @ unquote(expr)` as a way forward.

> Not sure how that allows one-pass parsing, though ? Well, hm, we'd know with a one-token lookahead... but that doesn't sound all that alluring now that I say it...

Ok, new suggestion that _really_ front-loads the unquote signal: `unquote(qtype @ expr)`

> But I think that, inherently, having splicing in a syntaxful language means you can't keep one-pass parsing. Or you're going to have to patch holes by yourself. That's an...

> that doesn't really simplify anything over `{{{`, does it? (...except it doesn't look as ugly) Oh, but it does, because `unquote(qtype @ expr)` introduces its three components in this...

Oh yeah, that one's equivalent as far as the above argument is concerned. Any reason I should prefer `{{{qtype @ expr}}}` to `unquote(qtype @ expr)` and not use this opportunity...

Here's one reason I've fallen out of love with `{{{ ... }}}`: [S06](http://design.perl6.org/S06.html#Splicing) talks a lot about custom delimiters for the `quasi` block, so you could have `quasi < ......

> Absolutely none! Except maybe that it doesn't stand out as much – which is fine for Lisp, since it has no syntax, but might not be for Perl 6/007....