Hyphenated keywords interacts badly with operator overloading

[John Rose]

On Jan 23, 2019, at 8:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I think the bigger point here is that some keywords/reserved identifiers  (this, null, true, false, and soon switch) can be used in expressions, and that we should be more careful hyphenating those.  Which is a point that was left out of the first mail.  


IIRC HK in expressions was briefly discussed but didn't seem
to offer any serious road-blocks.  Best case is we take extra
care when hyphenating `null`, `this`, `true`, and a few
other keywords.  Worst case is we hyphenate like crazy,
and get lexical-level ambiguities, which are resolved (as
usual) by the greedy rule:  The longest possible token
is parsed.  So `++x` is increment not `+/*…*/+x`.

In short, if we wish, we can sweep this problem under
an existing rug.

As long as we introduce HK before OO (likely!), and
mandate that any present or future HK gets greedily
lexed, then adding OO will not change the lexical
structure of any valid program, including in cases
where we add new HK's after OO.

(And, yes, there are already cases where a greedily
lexed token is immediately illegal, without further
analysis.  A very long string of decimal digits is
such a token. And so would be a nonsense HK.)

Example:  Suppose we add OO, and *after that* add
four-valued boolean logic including new keywords
`true-ish` and `false-ish`.  Any valid OO-using program
(oxymoron?) that includes expressions like `x=false-ish`
willi be invalid under the greedy rule because `false-ish`
is a reserved keyword, even if not defined.  The programmer
would have to throw in one or more spaces like `x=false - ish`.
Later on, the erroneous expression `x=false-ish` would
become a valid expression (using four-valued logic).

— John