Juxtaposing unary operators

[SDGGiesbrecht (Jeremy David Giesbrecht)]

@Nevin

Do I understand then that you are supportive of the idea in principle, but wary of implementation complexity and/or compiler performance?

Yes. Although I hadn’t thought about it that way when I posted. I hadn’t even noticed it was in the evolution category. I was only hypothesizing about the answer to your question:

@Nevin

Is there a reason why unary operators cannot be juxtaposed?

Ultimately, if implemented, it would be the first case of something not expressible in the Backhus‐Naur‐like grammar, since it relies on the semantics of external declarations (even if that part is delayed until a later phase of compilation by leaving it as a single stand‐in token to start with).

@Nevin

With the greedy approach, matching the full string is the first thing that is attempted. If it succeeds, then the process stops and no other possibilities are checked, because the longest one has already been found. That is what “greedy approach” means.

@Nevin

No, you would do that once, later on, during the type-checking phase, for the one specific sequence of operator names found by the greedy approach.

Then adding a new operator could break both the tokenization and/or type checking of existing expressions whose operators happen to be subsequences. ----x would be four negations until you restore C‐style -- as a custom operator, after which it would be two decrements and possibly a compiler complaint about mutability. (But I concede the example is contrived.)