On Mar 24, 2020, at 8:19 PM, Tagir Valeev <amae...@gmail.com> wrote:
>
> It looks weird to me. An arrow assumes some left-hand 'from' part, but
> it's absent here. Also, too easy to mix with actual lambda, to my
> taste. Still, better than nothing :-)
To me the interesting observation here is that we already have a way
for replacing an expression with a block, and this way works only
in certain contexts. That is, after “->” (that’s the context) you can
have an expression, but if you want a block instead, you wrap it in
(required) curly braces, and you also use a keyword “return” or
“yield” (choice depending further on context) to nominate the
value to use (instead of the expression) after executing the block.
So a block can replace an expression, but there is a moderately
gentle coloring: The curly braces are introduced (otherwise illegal
at that point) and the contents of the braces have a keyword
somewhere that nominates a value. I call it “gentle” because
there aren’t too many extra tokens, and “coloring” because it’s
there are special tokens that would not otherwise be present
in an expression. (In other languages like Lisp, expressions
and blocks are really the same kind of thing, the same color.)
Furthermore, this “gentle coloring” can only occur after an
arrow token. The effect is a little less gentle, because you
can visually scan for the pseudo-token “-> {” which stands
out a little more .
My point is that there’s a more or less continuous range of
design points between Lisp-like (so gentle and colorless as
to be invisible) and C-like (rigid separation between statements
and expressions). Java is less on the C-like end with the
introduction of “-> {”. That’s a good place to add more
sugar, if we want to. (I don’t think we do, at present,
but I argue there may be more compellingly powerful
abstractions in the future which would lead us to further
blur the line between statement and expression.)
FWIW (this is less of a principled argument) I agree with
you Tagir that the arrow token wants to connect two things,
and so looks jarring without anything on the left and/or,
as in Remi’s case, with an binary operator (“=”) before the
arrow. Given the visual clarity already present in the
sequence “-> {”, I think a lowly keyword “do” would not
get lost if it were given the job of providing the LHS of
the arrow, as in something like “do -> { foo(); yield bar(); }”.
But there are other reasons not to go there.
As I mentioned, I don’t this job is big enough to devote
a new syntax to it; there are bigger jobs that may warrant
such a syntax, with statement-expressions as a special case.
(Also, if “do -> { foo(); yield bar(); }” were a thing, then one
would also expect “do -> baz()” to be an alias for “baz()”,
but that seems like a silly outcome. Arrow statements are
a promising trick to play again and again, but whatever
we get from such tricks should also give us useful arrow
expressions.)
— John
