
We need more keywords - myinnerbanjo
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html
======
gizmo686
Another option is to enable language features on a per-file basis. That way
you could have your "ideal" syntax, and only have to do the work of updating
those files where you need to use it.

The only language I can think of that does this extensively is Haskell (and
some flavors of regular expressions). The main downside I have noticed is that
the ability to do this allows for the language to add a bunch of complexity
that would otherwise be prevented by the need to preserve backwards
compatibility [1]; but, if the language writers can remain disciplined, it
seems like an effective way to grow a language without the growing pains the
article is discussing.

For adding keywords, this approach doesn't even add that much maintenance
cost, as all the additional complexity is confined to the lexer.

[1] Or, as has happened several times with Haskell, add features that too
broken to even be considered adding but for the fact they are always behind a
flag.

~~~
chrisseaton
> Another option is to enable language features on a per-file basis.

Will you need a new keyword to enable your option for new keywords?

~~~
gizmo686
It works better if it is part of the language from the start.

Having said that, we can probably implement it using only existing keywords.
Maybe: import java.lang.extensions.assert.

(I assume Java has some reserved part of the package namespace they can use
for this purpose. Even if they don't, it shouldn't be difficult to find a
package name that hasn't been used by anyone yet)

------
nartz
If a user could alias or reassign certain keywords, it might be another
solution. That way, older projects only require a keywords mapping
configuration, and newer project probably will just use the default keywords.

------
tmpabcdefg123
Alternatively...Use a new file extension. That way you have a syntax version.
Repeat if you need. If you build into that syntax whatever means you need to
future extend keywords no need to repeat.

------
nextInt

      the lexer can always tell with fixed lookahead whether `a-b` is three tokens or one
    

How does that work? It doesn't seem obvious to me?

I also wonder what approaches other languages have taken since I haven't seen
dashed keywords in any of the other big languages.

~~~
ridiculous_fish
Ooh let's take a tour of big languages.

\- C has given up on new identifiers save the "reserved namespace", consisting
of an underscore followed by an Uppercase, which is how you get _Bool and
_Generic. Oof, nuff said.

\- C++ has stretched poor `static` to its limits, and now incorporates
context-sensitive "identifiers with special meaning": `final` and `override`.
No new hard keywords in C++17 AFAIK.

\- C# takes this even further with its LINQ-driven contextual keywords.

\- JavaScript stumbles about by adding new identifiers, BUT only in strict
mode, and even then only sometimes; `yield` is especially ambiguous.

Fill in the blanks please!

~~~
ygra
I think C# has only ever added contextual keywords after its initial release
and if I remember correctly there was only one breaking change for semantics
of source code, which I find impressive. I also didn't get the impression
(from working with Roslyn and looking at its source here and there, as well as
reading posts from people like Eric Lippert or Mads Torgersen about the
language design) that contextual keywords are as much of a hassle as Brian
makes them out to be. About the only really annoying one I can think of in C#
would be the nameof operator, which has to be parsed as a method invocation
and is only the nameof operator when there's no symbol with that unqualified
name accessible at that point that can be invoked as a method (e.g. an actual
method named nameof (rare), or a local variable of a delegate type). Pretty
much all other contextual keywords are only valid in a few places where
parsing is not ambiguous. You just happen to have a token there that's still
valid elsewhere as an identifier.

It's interesting to read about the musings and decision making processes for
different languages, though. I'm sure Java and C# are both designed very
carefully, yet with radically different goals and outcomes. And I'm sure both
language design teams must ponder pretty much the same issues.

