do expression
John Rose
john.r.rose at oracle.com
Tue Mar 24 04:55:41 UTC 2020
The keyword “do” is so short and sweet, and so under-used,
that it’s tempting to give it a new job.
But I don’t think this job is important enough. It’s just making
a little sugar for something you can express already with switch.
As Guy says there are many ways to wrap a block in an expression,
if we should want to do this. If we use a keyword, I would think
it should be a larger keyword than “do”, just to make it more
visible. Or, if invisibility is OK, perhaps no keyword at all is
OK, just “({ x })”: But that clearly shows the problems with
making the shift between statement and expression go almost
invisible; and “do” is like that also, just two characters.
We went round and round on these issues with lambdas,
because they are similar. It takes a long while to settle on
just the right syntax to (a) read well, (b) not be too noisy,
and (c) not be too invisible either.
Let’s keep “do” in reserve. There are much deeper things we can
eventually “do” with that keyword. In particular, if we open
up Java to allow extended execution modes, such as parallel
or differentiable or symbolic or side-effect-controlled, we will want
a concise way to mark the blocks of code which are to be “done”
in an extended execution mode. For my money, that’s worth
“doing up” with a pretty keyword.
Before anyone asks, no I don’t have a specific proposal for
such a thing. A first draft, IMO, will use something like
lambda cracking (or maybe a clumsier form of quoting)
to work out the details of how to abstract over evaluation
modes, and apply them independently of the code snippets
themselves. There’s a lot of experimentation to work
through first, with no sugar anywhere, before we would
be confident of the correct degrees of freedom, the
different ways to “do” code.
I “do” have an unspecific proposal: Look at F# computation
expression, and Haskell “do” syntax. They cannot be spliced
whole-sale into Java without many adjustments, but they are
examples of what I mean by abstracting apart mode of computation
from code-structure of computation. What’s required are two
chunks of ordinary-looking code, one to supply local rules for
evaluation, and one to execute, non-standardly, under the
local rules. I have no idea (1) what the looks in in detail
for Java, and (2) what the sugary syntax would be, but that’s
the sort of juicy feature where little old “do” might come
into its own, something like (OK, syntax) “using (x) do y”.
— John
On Mar 23, 2020, at 7:23 PM, Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> Now we have a legal way to execute several statements within an expression, yielding the result with a yield statement. This could be done via `switch` expression.
>
> Sometimes it's desired to do this without any switch. One may abuse the switch expression feature writing `switch(0) { default -> { ... code block ending with 'yield' }}`.
>
> How about creating a special syntax for such kind of expression. It could look like `do { ... code block ending with 'yield' }`?
>
> E.g. consider:
>
> class X {
> static final String field;
>
> // now we are forced to split field declaration and initialization
> // also initializer could be long and it could be not evident that its main purpose
> // is to initialize the field
> static {
> try {
> field = initializeField();
> }
> catch(CheckedException e) {
> throw new RuntimeException(e);
> }
> }
> }
>
> Since Java 14 we can write
>
> class X {
> // field declaration and initialization in the same place: easier to navigate through code
> // though we are abusing the switch expression
> static final String field = switch(0) { default -> {
> try {
> yield initializeField();
> }
> catch(CheckedException e) {
> throw new RuntimeException(e);
> }
> }};
> }
>
> It could be like
>
> class X {
> // concise syntax. Now we know that the main block purpose
> // is to initialize the field
> static final String field = do {
> try {
> yield initializeField();
> }
> catch(CheckedException e) {
> throw new RuntimeException(e);
> }
> };
> }
>
> It's similar to Perl 'do BLOCK' expression
> https://perldoc.perl.org/functions/do.html <https://perldoc.perl.org/functions/do.html>
>
> What do you think?
>
> With best regards,
> Tagir Valeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200323/2ea30f69/attachment.htm>
More information about the amber-spec-experts
mailing list