From forax at univ-mlv.fr  Tue Jun  6 06:56:23 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 6 Jun 2023 08:56:23 +0200 (CEST)
Subject: IN and OUT template processors ?
Message-ID: <1124946262.73434774.1686034583966.JavaMail.zimbra@univ-eiffel.fr>

Hi all,
thinking a little bit about STR and FMT, I wonder if we should not introduce also two other template processors, IN and OUT.

IN is the input template processor, it asks a user for a string on the standard input
  String name = IN."what is your name ?";

It works like input (raw_input) in Python or scanf in C.


OUT is the output template processor, it prints a string to the standard output
  OUT."Hello World!"

It works like print in Python or printf in C.


I believe IN and OUT work quite well when combined with the unamed class syntax

  void main() {
      String name = IN."what is your name ?";
      OUT."Hello \{name}";
  }


IN and OUT can be real classes (IO.Input and IO.Output *) so they can be completed by adding several useful static methods, like IN.input(), IN.inputAsInt(), etc and OUT.println(), OUT.printf(), etc

regards,
R?mi

* with IO being a class that provides simple static methods for reading/writing files

From brian.goetz at oracle.com  Tue Jun  6 14:03:16 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 6 Jun 2023 10:03:16 -0400
Subject: IN and OUT template processors ?
In-Reply-To: <1124946262.73434774.1686034583966.JavaMail.zimbra@univ-eiffel.fr>
References: <1124946262.73434774.1686034583966.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <00ae39cf-be7d-ce64-e7f2-83e3b7d10d40@oracle.com>


> thinking a little bit about STR and FMT, I wonder if we should not introduce also two other template processors, IN and OUT.
>
> IN is the input template processor, it asks a user for a string on the standard input
>    String name = IN."what is your name ?";
>
> It works like input (raw_input) in Python or scanf in C.

OMG, please no.? Having a template processor do side-effects would be 
awful.




From guy.steele at oracle.com  Tue Jun  6 14:46:22 2023
From: guy.steele at oracle.com (Guy Steele)
Date: Tue, 6 Jun 2023 14:46:22 +0000
Subject: IN and OUT template processors ?
In-Reply-To: <1124946262.73434774.1686034583966.JavaMail.zimbra@univ-eiffel.fr>
References: <1124946262.73434774.1686034583966.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <9E5F5B3D-F22E-4017-835B-5A92A6DC8313@oracle.com>

I agree that it may be desirable to have certain ?quick and easy? input/output mechanisms for use by novice programmers using the on-ramp (nameless classes), but I really don?t understand the motivation for conflating that with the string template mechanism?using side effects in string template processors could have a lot of drawbacks, and I don?t see that it has any advantages over simply using I/O methods with FMT templates other than perhaps a tiny amount of abbreviation. What am I missing?

?Guy

> On Jun 6, 2023, at 2:56 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ?Hi all,
> thinking a little bit about STR and FMT, I wonder if we should not introduce also two other template processors, IN and OUT.
> 
> IN is the input template processor, it asks a user for a string on the standard input
>  String name = IN."what is your name ?";
> 
> It works like input (raw_input) in Python or scanf in C.
> 
> 
> OUT is the output template processor, it prints a string to the standard output
>  OUT."Hello World!"
> 
> It works like print in Python or printf in C.
> 
> 
> I believe IN and OUT work quite well when combined with the unamed class syntax
> 
>  void main() {
>      String name = IN."what is your name ?";
>      OUT."Hello \{name}";
>  }
> 
> 
> IN and OUT can be real classes (IO.Input and IO.Output *) so they can be completed by adding several useful static methods, like IN.input(), IN.inputAsInt(), etc and OUT.println(), OUT.printf(), etc
> 
> regards,
> R?mi
> 
> * with IO being a class that provides simple static methods for reading/writing files

From forax at univ-mlv.fr  Tue Jun 13 19:17:25 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 Jun 2023 21:17:25 +0200 (CEST)
Subject: Money for Nothing, ...
Message-ID: <1095327035.80244534.1686683845970.JavaMail.zimbra@univ-eiffel.fr>

Hello,
currently, it's not possible to write a lot of generics sealed type because Java has no way to denote the bottom type.

By example, if a Result can be either a Success or an Error, we want to be able to write this kind of switch

  public static void main(String[] args) {
    Result<String, IOException> result = ...
    var val = switch(result) {
      case Error<IOException> error -> 1;
      case Success<String> success -> 2;
    };
  }

But i do not see a way to do that without introducing a way to denote the bottom type (named "Nothing" here)

  sealed interface Result<T,E extends Exception> {}
  record Error<E extends Exception>(E error) implements Result<Nothing, E> {}
  record Success<T>(T value) implements Result<T, Nothing> { }

Nothing being the return type of a method that either never terminate (by example, using a for(;;)) or always throw an exception.

So, should we add Nothing to Java or is there another way to model this kind of sealed types ?

regards,
R?mi

From daniel.smith at oracle.com  Wed Jun 14 17:34:08 2023
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 14 Jun 2023 17:34:08 +0000
Subject: Money for Nothing, ...
In-Reply-To: <1095327035.80244534.1686683845970.JavaMail.zimbra@univ-eiffel.fr>
References: <1095327035.80244534.1686683845970.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <904CDD31-E833-4752-BF2B-129E790C4118@oracle.com>



> On Jun 13, 2023, at 12:17 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hello,
> currently, it's not possible to write a lot of generics sealed type because Java has no way to denote the bottom type.
> 
> By example, if a Result can be either a Success or an Error, we want to be able to write this kind of switch
> 
>  public static void main(String[] args) {
>    Result<String, IOException> result = ...
>    var val = switch(result) {
>      case Error<IOException> error -> 1;
>      case Success<String> success -> 2;
>    };
>  }
> 
> But i do not see a way to do that without introducing a way to denote the bottom type (named "Nothing" here)
> 
>  sealed interface Result<T,E extends Exception> {}
>  record Error<E extends Exception>(E error) implements Result<Nothing, E> {}
>  record Success<T>(T value) implements Result<T, Nothing> { }
> 
> Nothing being the return type of a method that either never terminate (by example, using a for(;;)) or always throw an exception.
> 
> So, should we add Nothing to Java or is there another way to model this kind of sealed types ?

You're looking for a generics feature we don't have: a single object that implements multiple parameterizations of the same superinterface.

That is, you want:
Success<String> <: Result<String, IOException>
Success<String> <: Result<String, RuntimeException>
Success<String> <: Result<String, Throwable>
...

Academics have explored this, but it's a pretty deep change to how Java handles generics.

(A "bottom type" doesn't quite do it, because it needs to be paired with declaration-site variance.)

What the language requires instead is something like:

sealed interface Result<T,E extends Exception> {}
record Error<T,E extends Exception>(E error) implements Result<T,E> {}
record Success<T,E extends Exception>(T value) implements Result<T,E> { }

(Or rethinking whether this degree of generality is really necessary for the problem.)

From brian.goetz at oracle.com  Wed Jun 14 17:50:53 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 14 Jun 2023 13:50:53 -0400
Subject: Money for Nothing, ...
In-Reply-To: <1095327035.80244534.1686683845970.JavaMail.zimbra@univ-eiffel.fr>
References: <1095327035.80244534.1686683845970.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <4aed32d8-2e3c-7aed-c225-ac9142be3c58@oracle.com>

Here's how we would define this in Haskell:

 ??? data Result t = Succ t | Error Throwable

or maybe (Either-style)

 ??? data Result t e = Succ t | Error e

Note that in either, `Error` is still generic in `t`, its just that it 
doesn't use `t`, so it doesn't say `t`.? Similarly, in the latter, both 
alternatives are generic in both tvars, but each uses only one of them.

The Java analogue here is:

 ??? sealed interface Result<T> { }
 ??? record Succ<T>(T t) implements Result<T> { }
 ??? record Fail<T>(Throwable t) implements Result<T> { }

What you are probably reacting to here is "but why does Fail have to say 
T, it doesn't use it."? And the answer is: "get over that, and then 
you're done."

You are trying to invent a new generics feature to avoid putting a `T` 
you don't use in your Error declaration.? But that T (and maybe E) are 
needed to unify the two under Result<T,E> -- just like in the second 
Haskell example above.



On 6/13/2023 3:17 PM, Remi Forax wrote:
> Hello,
> currently, it's not possible to write a lot of generics sealed type because Java has no way to denote the bottom type.
>
> By example, if a Result can be either a Success or an Error, we want to be able to write this kind of switch
>
>    public static void main(String[] args) {
>      Result<String, IOException> result = ...
>      var val = switch(result) {
>        case Error<IOException> error -> 1;
>        case Success<String> success -> 2;
>      };
>    }
>
> But i do not see a way to do that without introducing a way to denote the bottom type (named "Nothing" here)
>
>    sealed interface Result<T,E extends Exception> {}
>    record Error<E extends Exception>(E error) implements Result<Nothing, E> {}
>    record Success<T>(T value) implements Result<T, Nothing> { }
>
> Nothing being the return type of a method that either never terminate (by example, using a for(;;)) or always throw an exception.
>
> So, should we add Nothing to Java or is there another way to model this kind of sealed types ?
>
> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230614/a7282b45/attachment-0001.htm>

From john.r.rose at oracle.com  Wed Jun 14 18:38:25 2023
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 14 Jun 2023 11:38:25 -0700
Subject: Money for Nothing, ...
In-Reply-To: <4aed32d8-2e3c-7aed-c225-ac9142be3c58@oracle.com>
References: <1095327035.80244534.1686683845970.JavaMail.zimbra@univ-eiffel.fr>
 <4aed32d8-2e3c-7aed-c225-ac9142be3c58@oracle.com>
Message-ID: <D0C96B18-A458-4B85-B493-782ED23EED47@oracle.com>

This is where some programmers will just reach for RuntimeException and 
go get their next coffee.

On 14 Jun 2023, at 10:50, Brian Goetz wrote:

> Here's how we would define this in Haskell:
>
> ??? data Result t = Succ t | Error Throwable
>
> or maybe (Either-style)
>
> ??? data Result t e = Succ t | Error e
>
> Note that in either, `Error` is still generic in `t`, its just that it 
> doesn't use `t`, so it doesn't say `t`.? Similarly, in the latter, 
> both alternatives are generic in both tvars, but each uses only one of 
> them.
>
> The Java analogue here is:
>
> ??? sealed interface Result<T> { }
> ??? record Succ<T>(T t) implements Result<T> { }
> ??? record Fail<T>(Throwable t) implements Result<T> { }
>
> What you are probably reacting to here is "but why does Fail have to 
> say T, it doesn't use it."? And the answer is: "get over that, and 
> then you're done."
>
> You are trying to invent a new generics feature to avoid putting a `T` 
> you don't use in your Error declaration.? But that T (and maybe E) 
> are needed to unify the two under Result<T,E> --
> just like in the second Haskell example above.
>
>
>
> On 6/13/2023 3:17 PM, Remi Forax wrote:
>> Hello,
>> currently, it's not possible to write a lot of generics sealed type 
>> because Java has no way to denote the bottom type.
>>
>> By example, if a Result can be either a Success or an Error, we want 
>> to be able to write this kind of switch
>>
>>    public static void main(String[] args) {
>>      Result<String, IOException> result = ...
>>      var val = switch(result) {
>>        case Error<IOException> error -> 1;
>>        case Success<String> success -> 2;
>>      };
>>    }
>>
>> But i do not see a way to do that without introducing a way to denote 
>> the bottom type (named "Nothing" here)
>>
>>    sealed interface Result<T,E extends Exception> {}
>>    record Error<E extends Exception>(E error) implements 
>> Result<Nothing, E> {}
>>    record Success<T>(T value) implements Result<T, Nothing> { }
>>
>> Nothing being the return type of a method that either never terminate 
>> (by example, using a for(;;)) or always throw an exception.
>>
>> So, should we add Nothing to Java or is there another way to model 
>> this kind of sealed types ?
>>
>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230614/b24c7968/attachment.htm>

From gavin.bierman at oracle.com  Thu Jun 22 09:13:14 2023
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Thu, 22 Jun 2023 09:13:14 +0000
Subject: [Resend] Draft Spec for Statements before Super() (JEP 447)
In-Reply-To: <CANSoFxtvZyiVvXD97jXx5g4bFs6qivx3FePmie68ZFoMt4k2ug@mail.gmail.com>
References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com>
 <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com>
 <D3A251B4-BF11-4B1D-B287-09C2C11FE5E6@oracle.com>
 <a21de630-1784-1d3b-910a-9451fb79b869@oracle.com>
 <CANSoFxtvZyiVvXD97jXx5g4bFs6qivx3FePmie68ZFoMt4k2ug@mail.gmail.com>
Message-ID: <36585870-BAAE-41B5-B151-EF29BEE14FBE@oracle.com>

I have updated the spec with these various suggestions. Thank you!

https://cr.openjdk.org/~gbierman/jep447/latest/

Gavin

On 30 May 2023, at 16:39, Archie Cobbs <archie.cobbs at gmail.com> wrote:

On Thu, May 18, 2023 at 2:33?PM Alex Buckley <alex.buckley at oracle.com<mailto:alex.buckley at oracle.com>> wrote:
However, the draft does not address how JLS20, at

https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.10.4-500

says

"A record declaration may contain declarations of constructors that are
not canonical constructors. The body of every non-canonical constructor
in a record declaration must *start with* an alternate constructor
invocation (?8.8.7.1), or a compile-time error occurs."

I assume the intent is to allow a non-canonical ctor in a record
declaration to *contain* an alternate ctor invocation, not just *start
with*? If so, please amend 8.10.4 in the draft.

Good catch - I agree that changing "start with" to "contain" is the right fix.

Gavin, will you update the spec draft please?

-Archie

--
Archie L. Cobbs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230622/524d28c0/attachment-0001.htm>