Could we change the syntax for when clauses?

[David Alayachew]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20221128/531e908f/attachment.htm>