Carl Mäsak

And, as it turns out, we can take the `` idea one step further — by not parsing that bit at all. All we really want is a term that...

> `prefix:` Actually, I don't remember my own decisions/speculations, it seems: we've already decided in #112 to go with `*` for this (from Python and Perl 6, instead of from...

Here's a shorter version: ``` use rest_parameters; macro term:reduce(op: Q::Infix) is parsed(/"[" "]"/) { my name = ...; # something nice and introspectable return quasi { (sub {{{name @ Q::Identifier}}}(*values)...

The `term:reduce` rule has as its declarative prefix `[`... as does the built-in `term:array`. The place where they differ is in the next atom, where the former has `` and...

We haven't even talked about `[\+]` yet. I wouldn't mind it. Dunno if it should be in a separate module? Probably not.

I decided not to refer to this as "the Elvis operator", since [Wikipedia](https://en.wikipedia.org/wiki/Elvis_operator) seems to be of the opinion that that's the name of another operator, usually spelled `?:` but...

[The TC39 proposal](https://github.com/tc39/proposal-optional-chaining) makes a good point I hadn't considered: the operator is _short-cricuiting_ such that any side effects happening on the rhs of a `?.` with a `none` lhs...

Having slept on it, I'm slightly more leaning towards never allowing the conflict in the first place. That is, `H(50)` gets to mean either, but it's always clear from the...

In the end, that's not so different from how `+++` could be any number of combinations of postfixes, infix, and prefixes, according to the lexical environment. (All within the bounds...

I think "parentheses after a term means function call" is a reasonable-enough rule to turn into an inviolable rule. But (stepping back a bit), the original problem is that parentheses...