Could we change the syntax for when clauses?

[David Alayachew]

 (copying my message here since I responded to the wrong thing)

Hello Brian,

Thank you for your response.

> As you point out, this isn’t really about `when`

Guilty as charged.

I see contextual keywords as a tactic that is useful when there is a phrase
that is so expressive/useful that it is worth the costs I mentioned in the
original post. There's definitely a time and a place for them. However, I
also feel like the budget for that has been mostly exhausted already, and
that from here on out, I'd like us to move away from this tactic.

> if we did as you say for `when`, you’d write exactly
> the same mail the next time we consider a contextual
> keyword.

To be clear, I certainly didn't and do not intend to raise this point again
without something major changing. I just felt like now was a useful time to
bring up this discussion because "when clauses" are in preview.

Also, I get the feeling that the keyword decision made here will likely set
the tempo for keyword choices moving forward. For example, it looks like
we'll all be seeing a lot more "switches" in Java's near future. So if
"when clauses" are received well, I am pretty certain that people will use
them as evidence to support using more contextual keywords in the future.
You can imagine my concern. Therefore, I'd like to catch it now while it's
still within reach.

> but others reading this exchange may not have (read
> the JEP Draft)

Thank you for pointing this out. I agree, and I will also provide a brief
summary here too.

In short, this JEP Draft takes advantage of 3 facts and combines them
together to create a new way to generate new Java keywords that are NOT
context-dependent.

First, there are "classic keywords" in Java that can NEVER be used as an
identifier. Here are a few.

final
int
double
if
case

Second, the hyphen (-) in Java is currently used to denote subtraction
(ignore the "non-sealed" keyword for now).

Third, you can ONLY perform subtraction upon identifiers, NEVER on "classic
keywords".

Therefore, if you combine these 3 facts, you can use the following strategy
to be able to create new keywords. The official name the JEP used is
"Hyphenated classic keywords".

If you make a keyword like

"record-class"

"record" is considered a valid identifier, but "class" can NEVER be a valid
identifier.

Therefore, if we follow the pattern of

IDENTIFIER --> HYPHEN --> KEYWORD

you can generate all sorts of keywords that are NOT context-dependent. This
allows all the language parser folks to simply look for a "classic
keyword", see if it is followed by or following a hyphen, then check for
the permitted "Hyphenated classic keywords".

And to be clear, the JEP Draft also suggests other strategies as well that
instead use context-dependent concepts. I am not talking about those, only
the paragraph of the JEP Draft titled "Hyphenated classic keywords".

> Whenever we consider new language syntax, we are
> called upon to make tradeoffs between many
> considerations

This was very informative, thank you. I had soft concepts for all of this,
but this explanation helped solidify where they apply and how we reason
about them. Thank you.

> (We bear most of this cost, but others in the
> ecosystem bear some as well.)

Thank you for highlighting this. Yes, none of my criticism here is to
belittle the scale of work being done. I want to make sure that we take the
steps that will cause us all the least amount of pain moving forward.


> Despite these challenges, usability remains paramount.
> (Remember too that many proposed hyphenated keywords
> are also contextual, unless one or both parts are
> existing keywords.).

Thank you for highlighting this. Yes, I think my suggestion contributes
nothing unless we use the "Hyphenated classic keywords" strategy.
Otherwise, we end up right back in the same hole with a different shovel.

> If there were a better candidate that didn’t have these
> challenges, we would have likely preferred that. We did
> try &&, which avoided this bullet, but which ultimately
> fell afoul of usabilty concerns.

Good to know. Could you tell me roughly the time when these discussions
happened on the mailing lists? I try very hard to research these things
before posting, but there's no search bar on the mailing list, and google
is rarely much help. Perhaps I need to get better at googling?

> No credible alternatives were proposed that avoided the
> problem; even most hyphenated options (e.g., `only-when`)
> were still contextual, and users would surely have
> complained “why do I have to type this long thing.”

I can imagine the Amber team's frustration. To be frank, the fact that it
is not 2 characters or less is going to cause some users to complain about
length. I struggle to find the motivation to appease them with my
suggestions.

> Did you have a better candidate in mind?

Here are a few. NONE of these suggestions are context-dependent (at least,
not in the way I have been describing thus far) since they all use a
"classic keyword" as part of the phrase.

- if ---------- Yes, I am proposing to repurpose the if statement here. The
concept that the "when clause" represents has strong similarities to an if
statement, so maybe this would allow us to build off of users existing
mental models? And it should appease all of the 2 char, code golf
enthusiasts as well.
- case-guard -- Verbose, but clear. No confusion on what this is or means.
If expressiveness/clarity was the only priority, this would likely be the
best choice.
- case-if ----- The middle ground between the above 2.
- only-if ----- Since "only-when" was suggested before, maybe this one?
It's no longer context-dependent now.

There are others to be found as well. I believe the below link has all of
the "classic keywords"? We can run through more permutations if none of
mine are good.

https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html
<------ Someone correct me if this list is not exhaustive or if it is out
of date.

Thank you for your time and insight!
David Alayachew

On Mon, Nov 28, 2022 at 9:38 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> As you point out, this isn’t really about `when`; if we did as you say for
> `when`, you’d write exactly the same mail the next time we consider a
> contextual keyword.  What you’re really asking is: “can we please stop
> using contextual keywords.”  (You’ve clearly read
> https://bugs.openjdk.org/browse/JDK-8223002 (“Keyword Management for the
> Java Language”), but others reading this exchange may not have, any may
> benefit from going back and reading it.).
>
> Whenever we consider new language syntax, we are called upon to make
> tradeoffs between many considerations, including:
>
>  - Compatibility with the existing language.  (We could declare `when` to
> be a real keyword, but that would break any code that uses it as an
> identifier.)
>  - Naturalness of the improved language.  (We could pick a new keyword
> that is unlikely to conflict with existing code, like
> `guardedByTheFollowingBooleanCondition`, but writing code in this language
> would be unpleasant.)
>  - Complexity for tools and specification.  (We bear most of this cost,
> but others in the ecosystem bear some as well.)
>  - Progress vs stagnation.  (We could choose not to do guards at all.)
>
> The “keyword management” JEP explicitly acknowledges the challenges with
> contextual keywords:
>
> *Cautiously consider contextual keywords*
>
> At first glance, unitary contextual keywords (and their friends, reserved
> type names) appear to be a magic wand: they let language designers create
> the illusion of new keywords without breaking existing programs. However,
> the positive track record of unitary contextual keywords hides a great deal
> of complexity and distortion.
>
> The process of introducing a unitary contextual keyword is not a simple
> matter of choosing a word and adding it to the grammar; each one requires
> an analysis of potential current and future interactions. Each grammar
> position is its own story: contextual keywords that might be used as
> modifiers (e.g., readonly) have different ambiguity considerations than
> those that might be used in code (e.g., a match expression). While a
> small number of special situations can be managed in a specification or a
> compiler, the more heavily that unitary contextual keywords are used, the
> more likely there would be more significant maintenance costs and longer
> bug tails.
>
> Beyond specifications and compilers, unitary contextual keywords distort
> the language for IDEs. IDEs often have to guess whether an identifier is
> meant to be an identifier or a unitary contextual keyword, and it may not
> have enough information to make a good guess until it has seen more input.
> While this is easy to dismiss as “not my problem”, in reality, it results
> in worse code highlighting, auto-completion, and refactoring abilities for
> everybody. (IDEs have the same trouble with hyphenated contextual keywords
> too.)
>
> Finally, each identifier that is a candidate for dual-purposing as a
> unitary contextual keyword may have its own special considerations. For
> example, the use of var as a restricted identifier is justified only
> because the naming conventions for type names
> <https://docs.oracle.com/javase/specs/jls/se12/html/jls-6.html#jls-6.1> are
> so broadly adhered to. Using a hyphenated contextual keyword rather than a
> unitary contextual keyword can sidestep these considerations, since the
> hyphenated phrase has never been used as an identifier, though the
> ambiguity issue remains.
>
> In summary, unitary contextual keywords are a tool in the language design
> toolbox, but they should be used with care.
>
>
> Despite these challenges, usability remains paramount.  (Remember too that
> many proposed hyphenated keywords are also contextual, unless one or both
> parts are existing keywords.).
>
> If there were a better candidate that didn’t have these challenges, we
> would have likely preferred that.  We did try &&, which avoided this
> bullet, but which ultimately fell afoul of usabilty concerns.  No credible
> alternatives were proposed that avoided the problem; even most hyphenated
> options (e.g., `only-when`) were still contextual, and users would surely
> have complained “why do I have to type this long thing.”
>
> Did you have a better candidate in mind?
>
>
> On Nov 27, 2022, at 7:07 PM, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Amber Dev Team,
>
> In regards to when clauses, is it possible that we could use a keyword for
> when clauses that is not the "context-dependent" style keyword? And when I
> say "context-dependent", I mean that the word "when" is a valid identifier,
> but we are using context to be able to figure out where it should be
> treated as a keyword vs. an identifier.
>
> The reason I am requesting this is because everytime a context-dependent
> keyword is added to Java, all the developers who make language/grammar
> parsing tools for the Java language have to rewrite/uproot nontrivial parts
> of their code to deal with several finnicky edge cases. It bogs down so
> much of the parsing logic that a lot of potential optimizations or cleaner
> solutions go out of the window. This leads to buggy code and/or features
> not being supported. Much of that could be avoided by choosing a keyword
> that is not context-dependent. I understand that there does exist a grammar
> for the language, but because
>
> Personally, I'd like it if as a language, Java never used this tactic for
> any new language feature. But for now, I am only requesting that we use a
> non-context-dependent phrase to signify when clauses. One suggestion would
> be to use the "Hyphenated classic keyword" strategy discussed in this JEP
> Draft (https://openjdk.org/jeps/8223002).
>
> Thank you for your time and patience!
> David Alayachew
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221128/a29cc886/attachment-0001.htm>