> On May 13, 2019, at 10:28 AM, Doug Lea <[email protected]> wrote:
>
>
> Having lost (nearly) this argument years ago, I'm not sure why I bother, but
> ...
>
> On 5/12/19 3:38 PM, Brian Goetz wrote:
>>
>> Looking at what other languages have done here, there are a few broad
>> directions:
>>
>> - A statement like “break-with v”, indicating that the enclosing structured
>> expression is completing normally with the provided value.
>> - An operator that serves the same purpose, such as “-> e”.
>> - Assigning to some magic variable (this is how Pascal indicates the return
>> value of a function).
>> - Treating the last expression in the block as the result.
>
> (The last one being "progn", the earliest and arguably still best of these.)
>
>>
>> I think we can dispatch all but the first relatively easily: ...
>>
>>
>> - Everywhere else in the language (such as method bodies), you are free to
>> yield up a value from the middle of the block, perhaps from within a control
>> construct like a loop; restricting the RHS of case blocks to put their
>> result last would be a significant new restriction, and would limit the
>> ability to refactor to/from methods. And further, the convention of putting
>> the result last, while a fine one for a language that is “expressions all
>> the way down”, would likely be too subtle a cue in Java.
>
> Last time around, the last point about subtlety and odd-lookingness of progn
> seemed to bother people the most. It is possible to make it less subtle by
> additionally requiring some symbol. Prefix "^" is still available. Allowing
> for example:
>
>
> String s = (foo != null)
> ? s
> : { println(“null again at line” + __LINE__); ^ “null”; };
>
> Which still lgtm….
Could be worse, but looks to be like Java with a Smalltalk accent—just as
{ foo(); bar }
is Java with a Lisp (or ECL) accent. I would prefer to adapt a bit of syntax
from ECL: the statement
b => e;
evaluates b as a boolean expression, and if it is true, then e is evaluated and
its value becomes the value of the block. This gives you a syntax very similar
to that of Lisp COND:
{ x > y => 1; x < y => -1; true => 0; }
If you then want to further abbreviate “true =>”, well, that’s another story,
but I wouldn’t blame you.
—Guy
