switch statement and lambda

[Remi Forax]

Currently this code doesn't compile
  IntConsumer c = x -> switch(x) { default -> System.out.println(x); };

I believe it should because this is the basic pattern for supporting the actor 
model,
you consume a message and do a side effect* depending on the type of the 
message,
translated in Java, you want a lambda that takes a message as parameter, calls 
a switch to do the pattern matching and return void.
 
The other reason is that it's not rare to move from a switch expression to a 
switch statement and vice-versa when developing the code,
and adding/removing a pair of curly braces around the code you are writing 
because it's the body/expression of a lambda is not very user friendly.

regards,
Rémi

* it's cleaner in Erlang because you have tail calls, so the side effects are 
hidden.

Re: String reboot (plain text)

[Brian Goetz]

> 
> I understand that you want to separate the steps and build a consensus,
> i think we are spending a lot of time on the raw part, we should decide a 
> syntax and move to the real question, do we offer support for alignment 
> directly in the language or not ?

I prefer to move directly on to the real question, and then discuss syntax :)   
Among others reasons, picking a syntax often implicitly constrains the 
solution, before you know what the right questions are.  Of course, there is 
the ongoing challenge that, when discussing questions and possible answers, one 
has to use _something_ to illustrate what you mean, and of course then people 
will want to discuss the syntax.  And we’re going to resist that urge, even 
though this feature has a higher syntax quotient than most.  

I agree that raw-ness was a distraction in the first round, which is why I 
placed it at (2) in my list of steps.  And right now, we’re still at 1 / 1a.  
In the first round, we got wrapped around the axle with raw-ness so early, we 
didn’t even stop to think about the bigger problem, multi-line.  (It is 
tempting, as I mentioned before, to consider multi-line to be “just” a special 
case of raw, and while that’s a possible outcome, there are some really good 
reasons to consider it on its own first.). 

Jim is working on some organized thoughts for 1a, stay tuned.

Re: String reboot (plain text)

[forax]

> De: "Brian Goetz" 
> À: "Remi Forax" 
> Cc: "amber-spec-experts" 
> Envoyé: Samedi 6 Avril 2019 18:14:00
> Objet: Re: String reboot (plain text)

> Yes, because when I said “these are for the later part of the discussion, 
> we’re
> going to leave it to sit until then”, what I meant of course was “please post
> your opinions on it now”…
ok, ok, no syntax, what i should have said is that any prefix/suffix will do 
the job. 

I understand that you want to separate the steps and build a consensus, 
i think we are spending a lot of time on the raw part, we should decide a 
syntax and move to the real question, do we offer support for alignment 
directly in the language or not ? 

Rémi 

>> On Apr 6, 2019, at 11:52 AM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
>> fo...@univ-mlv.fr ] > wrote:

>> I lke the r prefix because most people think the r prefix means regular
>> expression.

>> Rémi

>>> De: "Brian Goetz" < [ mailto:brian.go...@oracle.com | 
>>> brian.go...@oracle.com ] >
>>> À: "amber-spec-experts" < [ mailto:amber-spec-experts@openjdk.java.net |
>>> amber-spec-experts@openjdk.java.net ] >
>>> Envoyé: Samedi 6 Avril 2019 17:47:25
>>> Objet: Fwd: String reboot (plain text)

>>> Received on amber-spec-comments. These are mostly comments on syntax options
>>> that are for later parts of the discussion, so I’m reading them into the 
>>> record
>>> now, and we’re going to leave them to sit until then.

>>> High-order summary:
>>> - Please consider prefixes a”…” for auto-align and r”…” for raw.

 Begin forwarded message:

 From: Stephen Colebourne < [ mailto:scolebou...@joda.org | 
 scolebou...@joda.org
 ] >
 Subject: Re: String reboot (plain text)
 Date: March 21, 2019 at 11:14:53 AM EDT
 To: [ mailto:amber-spec-comme...@openjdk.java.net |
 amber-spec-comme...@openjdk.java.net ]
 Cc: Brian Goetz < [ mailto:brian.go...@oracle.com | brian.go...@oracle.com 
 ] >

 On Wed, 13 Mar 2019 at 17:52, Brian Goetz < [ 
 mailto:brian.go...@oracle.com |
 brian.go...@oracle.com ] > wrote:

> So, in the spirit of “keep ordering until sated, but stop there”, here 
> are some
> reasonable choices.

> 1. Do multi-line (escaped) strings with a “”” fixed delimiter. Large 
> benefit,
> small cost. Most embedded snippets don’t need any escaping. Low cost, big
> payoff.

> 1a. Do 1, but automatically reflow multi-line strings using the 
> equivalent of
> String::align. There have been reasonable proposals on how to do this; 
> where
> they fell apart is the interaction with raw-ness, but if we separate ML 
> and
> raw, these become reasonable again. Higher cost, but higher payoff; having
> separated the interaction with raw strings, this is more defensible.

> 2. Do (1) or (1a), and add: single-line raw string literals delimited by 
> \”…”\.

> 2a. Do (1) or (1a), and also support multi-line raw string literals 
> (where we
> _don’t_ automatically apply String::align; this can be done manually). 
> Note
> that this creates anomalies for multi-line raw string literals starting 
> with
> quotes (this can be handled with concatenation, and having separated ML 
> and
> raw, this is less of a problem than before).

> 3. Do (2) and (2a), and also support a repeating compound delimiter with
> multiple backslashes and a quote.

 My views have not changed dramatically from my last mail [1]. As per
 these options, I think the language would benefit from 1, 1a, 2 and 2a
 type changes. I think the choice between 1 and 1a is a false one. I'm
 not convinced 3 is worth pursuing.

 I agree that triple double-quote is the right mechanism for multi-line
 strings - an obvious direction for Java. I'm happy to accept 1 on its
 own *providing that 1a can be added later*. My preference is for """
 to be the delimiter for non-aligned multi-line strings, and for a
 single letter prefix 'a' to be used for aligned strings, eg. a""" ...
 """

 For raw strings I personally find the syntax /" ... "/ or /""" ...
 """/ unpleasant. While the argument of "distributing the escape over
 the string" makes some sense in the abstract, the result is not
 appealing to read. Given that I believe aligned and non-aligned
 strings should be separated by a single letter prefix, I believe that
 raw strings and non-raw strings should also be separated by a single
 letter prefix:

 """ - multi-line with-escapes & non-aligned
 a""" - multi-line with-escapes & aligned
 r""" - multi-line raw & non-aligned
 ra""" - multi-line raw & aligned
 " - single-line with-escapes
 r" - single-line raw

 And yes, I do think you can have raw and aligned as a combination. I
 think using prefix letters is more extensible, more orthogonal and
 clearer than using /""" ... """/.

 thanks
 Stephen

 [1] [ 
 https://mail.o

Re: String reboot (plain text)

[Brian Goetz]

Yes, because when I said “these are for the later part of the discussion, we’re 
going to leave it to sit until then”, what I meant of course was “please post 
your opinions on it now”…




> On Apr 6, 2019, at 11:52 AM, Remi Forax  wrote:
> 
> I lke the r prefix because most people think the r prefix means regular 
> expression.
> 
> Rémi
> 
> De: "Brian Goetz" 
> À: "amber-spec-experts" 
> Envoyé: Samedi 6 Avril 2019 17:47:25
> Objet: Fwd: String reboot (plain text)
> Received on amber-spec-comments.  These are mostly comments on syntax options 
> that are for later parts of the discussion, so I’m reading them into the 
> record now, and we’re going to leave them to sit until then.  
> 
> High-order summary:
>  - Please consider prefixes a”…” for auto-align and r”…” for raw.  
> 
> Begin forwarded message:
> 
> From: Stephen Colebourne mailto:scolebou...@joda.org>>
> Subject: Re: String reboot (plain text)
> Date: March 21, 2019 at 11:14:53 AM EDT
> To: amber-spec-comme...@openjdk.java.net 
> 
> Cc: Brian Goetz mailto:brian.go...@oracle.com>>
> 
> On Wed, 13 Mar 2019 at 17:52, Brian Goetz  > wrote:
> So, in the spirit of “keep ordering until sated, but stop there”, here are 
> some reasonable choices.
> 
> 1.  Do multi-line (escaped) strings with a “”” fixed delimiter.  Large 
> benefit, small cost.  Most embedded snippets don’t need any escaping.  Low 
> cost, big payoff.
> 
> 1a.  Do 1, but automatically reflow multi-line strings using the equivalent 
> of String::align.  There have been reasonable proposals on how to do this; 
> where they fell apart is the interaction with raw-ness, but if we separate ML 
> and raw, these become reasonable again.  Higher cost, but higher payoff; 
> having separated the interaction with raw strings, this is more defensible.
> 
> 2.  Do (1) or (1a), and add: single-line raw string literals delimited by 
> \”…”\.
> 
> 2a.  Do (1) or (1a), and also support multi-line raw string literals (where 
> we _don’t_ automatically apply String::align; this can be done manually).  
> Note that this creates anomalies for multi-line raw string literals starting 
> with quotes (this can be handled with concatenation, and having separated ML 
> and raw, this is less of a problem than before).
> 
> 3.  Do (2) and (2a), and also support a repeating compound delimiter with 
> multiple backslashes and a quote.
> 
> My views have not changed dramatically from my last mail [1]. As per
> these options, I think the language would benefit from 1, 1a, 2 and 2a
> type changes. I think the choice between 1 and 1a is a false one. I'm
> not convinced 3 is worth pursuing.
> 
> I agree that triple double-quote is the right mechanism for multi-line
> strings - an obvious direction for Java. I'm happy to accept 1 on its
> own *providing that 1a can be added later*. My preference is for """
> to be the delimiter for non-aligned multi-line strings, and for a
> single letter prefix 'a' to be used for aligned strings, eg. a""" ...
> """
> 
> For raw strings I personally find the syntax /" ... "/ or /""" ...
> """/ unpleasant. While the argument of "distributing the escape over
> the string" makes some sense in the abstract, the result is not
> appealing to read. Given that I believe aligned and non-aligned
> strings should be separated by a single letter prefix, I believe that
> raw strings and non-raw strings should also be separated by a single
> letter prefix:
> 
> """ - multi-line with-escapes & non-aligned
> a""" - multi-line with-escapes & aligned
> r""" - multi-line raw & non-aligned
> ra""" - multi-line raw & aligned
> " - single-line with-escapes
> r" - single-line raw
> 
> And yes, I do think you can have raw and aligned as a combination. I
> think using prefix letters is more extensible, more orthogonal and
> clearer than using /""" ... """/.
> 
> thanks
> Stephen
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/amber-dev/2019-January/003850.html 
> 
> 
> 

Re: String reboot (plain text)

[Remi Forax]

I lke the r prefix because most people think the r prefix means regular 
expression. 

Rémi 

> De: "Brian Goetz" 
> À: "amber-spec-experts" 
> Envoyé: Samedi 6 Avril 2019 17:47:25
> Objet: Fwd: String reboot (plain text)

> Received on amber-spec-comments. These are mostly comments on syntax options
> that are for later parts of the discussion, so I’m reading them into the 
> record
> now, and we’re going to leave them to sit until then.

> High-order summary:
> - Please consider prefixes a”…” for auto-align and r”…” for raw.

>> Begin forwarded message:

>> From: Stephen Colebourne < [ mailto:scolebou...@joda.org | 
>> scolebou...@joda.org
>> ] >
>> Subject: Re: String reboot (plain text)
>> Date: March 21, 2019 at 11:14:53 AM EDT
>> To: [ mailto:amber-spec-comme...@openjdk.java.net |
>> amber-spec-comme...@openjdk.java.net ]
>> Cc: Brian Goetz < [ mailto:brian.go...@oracle.com | brian.go...@oracle.com ] 
>> >

>> On Wed, 13 Mar 2019 at 17:52, Brian Goetz < [ mailto:brian.go...@oracle.com |
>> brian.go...@oracle.com ] > wrote:

>>> So, in the spirit of “keep ordering until sated, but stop there”, here are 
>>> some
>>> reasonable choices.

>>> 1. Do multi-line (escaped) strings with a “”” fixed delimiter. Large 
>>> benefit,
>>> small cost. Most embedded snippets don’t need any escaping. Low cost, big
>>> payoff.

>>> 1a. Do 1, but automatically reflow multi-line strings using the equivalent 
>>> of
>>> String::align. There have been reasonable proposals on how to do this; where
>>> they fell apart is the interaction with raw-ness, but if we separate ML and
>>> raw, these become reasonable again. Higher cost, but higher payoff; having
>>> separated the interaction with raw strings, this is more defensible.

>>> 2. Do (1) or (1a), and add: single-line raw string literals delimited by 
>>> \”…”\.

>>> 2a. Do (1) or (1a), and also support multi-line raw string literals (where 
>>> we
>>> _don’t_ automatically apply String::align; this can be done manually). Note
>>> that this creates anomalies for multi-line raw string literals starting with
>>> quotes (this can be handled with concatenation, and having separated ML and
>>> raw, this is less of a problem than before).

>>> 3. Do (2) and (2a), and also support a repeating compound delimiter with
>>> multiple backslashes and a quote.

>> My views have not changed dramatically from my last mail [1]. As per
>> these options, I think the language would benefit from 1, 1a, 2 and 2a
>> type changes. I think the choice between 1 and 1a is a false one. I'm
>> not convinced 3 is worth pursuing.

>> I agree that triple double-quote is the right mechanism for multi-line
>> strings - an obvious direction for Java. I'm happy to accept 1 on its
>> own *providing that 1a can be added later*. My preference is for """
>> to be the delimiter for non-aligned multi-line strings, and for a
>> single letter prefix 'a' to be used for aligned strings, eg. a""" ...
>> """

>> For raw strings I personally find the syntax /" ... "/ or /""" ...
>> """/ unpleasant. While the argument of "distributing the escape over
>> the string" makes some sense in the abstract, the result is not
>> appealing to read. Given that I believe aligned and non-aligned
>> strings should be separated by a single letter prefix, I believe that
>> raw strings and non-raw strings should also be separated by a single
>> letter prefix:

>> """ - multi-line with-escapes & non-aligned
>> a""" - multi-line with-escapes & aligned
>> r""" - multi-line raw & non-aligned
>> ra""" - multi-line raw & aligned
>> " - single-line with-escapes
>> r" - single-line raw

>> And yes, I do think you can have raw and aligned as a combination. I
>> think using prefix letters is more extensible, more orthogonal and
>> clearer than using /""" ... """/.

>> thanks
>> Stephen

>> [1] [ 
>> https://mail.openjdk.java.net/pipermail/amber-dev/2019-January/003850.html
>> | https://mail.openjdk.java.net/pipermail/amber-dev/2019-January/003850.html 
>> ]

Fwd: String reboot (plain text)

[Brian Goetz]

Received on amber-spec-comments.  These are mostly comments on syntax options 
that are for later parts of the discussion, so I’m reading them into the record 
now, and we’re going to leave them to sit until then.  

High-order summary:
 - Please consider prefixes a”…” for auto-align and r”…” for raw.  

> Begin forwarded message:
> 
> From: Stephen Colebourne 
> Subject: Re: String reboot (plain text)
> Date: March 21, 2019 at 11:14:53 AM EDT
> To: amber-spec-comme...@openjdk.java.net
> Cc: Brian Goetz 
> 
> On Wed, 13 Mar 2019 at 17:52, Brian Goetz  wrote:
>> So, in the spirit of “keep ordering until sated, but stop there”, here are 
>> some reasonable choices.
>> 
>> 1.  Do multi-line (escaped) strings with a “”” fixed delimiter.  Large 
>> benefit, small cost.  Most embedded snippets don’t need any escaping.  Low 
>> cost, big payoff.
>> 
>> 1a.  Do 1, but automatically reflow multi-line strings using the equivalent 
>> of String::align.  There have been reasonable proposals on how to do this; 
>> where they fell apart is the interaction with raw-ness, but if we separate 
>> ML and raw, these become reasonable again.  Higher cost, but higher payoff; 
>> having separated the interaction with raw strings, this is more defensible.
>> 
>> 2.  Do (1) or (1a), and add: single-line raw string literals delimited by 
>> \”…”\.
>> 
>> 2a.  Do (1) or (1a), and also support multi-line raw string literals (where 
>> we _don’t_ automatically apply String::align; this can be done manually).  
>> Note that this creates anomalies for multi-line raw string literals starting 
>> with quotes (this can be handled with concatenation, and having separated ML 
>> and raw, this is less of a problem than before).
>> 
>> 3.  Do (2) and (2a), and also support a repeating compound delimiter with 
>> multiple backslashes and a quote.
> 
> My views have not changed dramatically from my last mail [1]. As per
> these options, I think the language would benefit from 1, 1a, 2 and 2a
> type changes. I think the choice between 1 and 1a is a false one. I'm
> not convinced 3 is worth pursuing.
> 
> I agree that triple double-quote is the right mechanism for multi-line
> strings - an obvious direction for Java. I'm happy to accept 1 on its
> own *providing that 1a can be added later*. My preference is for """
> to be the delimiter for non-aligned multi-line strings, and for a
> single letter prefix 'a' to be used for aligned strings, eg. a""" ...
> """
> 
> For raw strings I personally find the syntax /" ... "/ or /""" ...
> """/ unpleasant. While the argument of "distributing the escape over
> the string" makes some sense in the abstract, the result is not
> appealing to read. Given that I believe aligned and non-aligned
> strings should be separated by a single letter prefix, I believe that
> raw strings and non-raw strings should also be separated by a single
> letter prefix:
> 
> """ - multi-line with-escapes & non-aligned
> a""" - multi-line with-escapes & aligned
> r""" - multi-line raw & non-aligned
> ra""" - multi-line raw & aligned
> " - single-line with-escapes
> r" - single-line raw
> 
> And yes, I do think you can have raw and aligned as a combination. I
> think using prefix letters is more extensible, more orthogonal and
> clearer than using /""" ... """/.
> 
> thanks
> Stephen
> 
> [1] https://mail.openjdk.java.net/pipermail/amber-dev/2019-January/003850.html