Expanding the "expression syntax"

[Brian Goetz]

Just a gentle reminder — this is straying pretty far outside the charter of amber-dev.

Amber-dev is primarily for collaboration on the _implementation_ of Project Amber.  This includes things like bug reports and experience reports, “how does it work” queries, etc.  We do interpret the charter pretty broadly, and so when discussion briefly steps outside the bounds, that’s usually not a problem.

But, amber-dev is definitely *not* the “I have a new idea for Java” discussion list.  With 10M developers, and each of them having two or three favorite feature ideas, such discussion could easily overwhelm the actual work that is going on.   So probably best to mostly limit to features that are actually under development within Project Amber.

Thanks,
-Brian


On Apr 5, 2023, at 10:51 AM, Red IO <redio.development at gmail.com<mailto:redio.development at gmail.com>> wrote:

Yes I know this python syntax.
To make it clear saying that I'm not a fan of python would be an understatement.
But even the python creator labeled the loop else as his biggest mistake.
And adding "the biggest mistake" of my least favorite language to java is definitely not in my interest.

When you look in another direction like rust which already features the "everything is an expression" mindset you can see that for and while loops where purposefully left out because of this exact dilemma. Rust features a special endless loop expression which can be an expression when static analysis can confirm that "yield" will be hit eventually or loop forever.
But I don't see java adding this loop type and treating a "while(true)" which is the practical equivalent specially would be weird.

Great regards
RedIODev

On Wed, Apr 5, 2023, 19:27 Adowrath <adowrath at protonmail.ch<mailto:adowrath at protonmail.ch>> wrote:

Actually, regarding the `else` block/branch for a loop, there's almost a precedence for this in Python: for and while loops can have an `else` block that executes after the loop has finished, iff no break statement (or, of course, return) was hit inside of the loop, only that this doesn't elevate the loop to an expression. Using the same logic for yielding from an expression loop could work equally - the downside is that even in Python it's considered quite uncommon/unusual syntax.

Regards,
Adowrath

Am 2023-04-05 um 19:17 schrieb Red IO:
I actually tried this exactly with annotation processor "hacks" I then realized that a loop might execute 0 times or never conditionally hit a yield statements. This results in the expression sometimes not yielding a result which wouldn't allow an assignment to a final variable and confusing errors like "variable might not be initialized" the only solution would be to add an else block to a loop that os executed when no yield was hit in the loop body (which would be ugly and confusing in my opinion)
That's why I stepped down from generalizing yield to all control flow elements to specially allow yield in try.

Great regards
RedIODev

On Wed, Apr 5, 2023, 16:27 Holo The Sage Wolf <holo3146 at gmail.com<mailto:holo3146 at gmail.com>> wrote:
A different approach is to give `yield` the same semantics as `break`, and interpreting `break label` as `yield label null`, this would make all label blocks be expressions.

The only thing we need to be careful with is finally block, but this situation already happens with `return` inside of a finally block, so I don't think we need to handle this situation differently

On Wed, Apr 5, 2023, 15:55 Tagir Valeev <amaembo at gmail.com<mailto:amaembo at gmail.com>> wrote:
Hello!

Just for the record, three years ago I posted a similar, though more universal proposal, "do expressions":
https://mail.openjdk.org/pipermail/amber-spec-experts/2020-March/002046.html

With best regards,
Tagir Valeev.

On Wed, Apr 5, 2023 at 11:58 AM Red IO <redio.development at gmail.com<mailto:redio.development at gmail.com>> wrote:
I did some more research and testing and concluded that loop expressions are more difficult to achieve than I thought and are not as simple as I thought.
So I limit my proposal to try expressions since I really think they are worth it.
A try expression would follow this syntax:
TARGET VARIABLE = TRY_KEYWORD [RECOURSE_BLOCK] TRY_BODY(with every path leading to a yield or throw) [CATCH_BLOCKS(with also a yield or throw in every path)]
[FINALLY_BLOCK (with no yield but throw possible)];

An example would be:
int fileInt = try (var reader = new BufferedReader(new FileReader("test.txt"))) {
var line = reader.readLine();
if (line == null)
yield -1;
yield Integer.parseInt(line);
} catch (IOException e) {
throw new CustomException("Couldn't open file", e);
} catch (NumberFormatException e) {
yield -1;
} finally {
if (outsideCondition)
throw new CustomCancelledExecption();
System.out.println("file read done");
};

This example is constructed to feature all possible parts of the syntax and is not necessarily code that makes sense to write.

Great regards
RedIODev

On Sat, Mar 4, 2023, 10:55 Red IO <redio.development at gmail.com<mailto:redio.development at gmail.com>> wrote:
Currently we have the switch expression as the only expression returning a result.
Example:
boolean b = switch (1) {
case 0 -> false;
case 1 -> {
yield true;
}
};

The idea would be to expand this syntax to different expressions for example the try expression:

int i = try {
yield Integer.parseInt("Abc");
} catch (NumberFormatException e) {
yield -1;
};

Or loops:

String searched = for(String s : args) {
if (s.startsWith("-"))
yield s;
};

The idea is to make all java control flow expressions able to yield a value.

Among many new patterns possible like the examples above it would for example "clean up" the exception catching initialization:

Foo foo = null;

try {
foo = new Foo();
} catch (SomeException e) {
//do something or nothing
} finally {
//maybe change the value again
}

To

var foo = try {
yield new Foo();
} catch (SomeException e) {
//throw or yield
} finally {
//throw or do nothing
};

Another benefit especially in this example is the clearer state of the result. In an yielding expression you have to either yield or throw. Also subsequent manipulation in for example the finally block is not possible making the source of the returned result clear to identify.

Great regards
RedIODev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230405/a96b9da2/attachment-0001.htm>