A peek at the roadmap for pattern matching and more

[John Rose]

On Aug 13, 2020, at 12:39 PM, Guy Steele <guy.steele at oracle.com> wrote:
> 
> Whereas I can more easily understand that the job of
> 
>     public deconstructor Point(int x, int y) {
>         x = this.x;
>         y = this.y;
>     }
> 
> is to take values out of the object “this” and put them into separate _variables_, not a new object.  (Granted, these variables have a somewhat new and mysterious existence and character.)

And if this mysterious character were something completely unrelated
to any other part of the Java language, I’d be more inclined to admit
that maybe the missing primitive is some sort of tuple.  It might have
to be given a status like that of Java arrays to avoid the infinite regress
problem you point out.

BUT, when I stare at a block of code that is setting some named/typed
variables, where those variables must be DA at the end of the block,
and then they are to be available in various other scopes (not the
current scope, but other API points), THEN I say, “where have I
seen that pattern before…?”  There is ALREADY a well-developed
part of the Java language which covers this sort of workflow
(of putting values into a set of required named/typed variables).

Of course, it’s a constructor, especially when the object has final
fields that are checked by the DA/DU rules.  Now, maybe those rules
aren’t everybody’s favorite; they are complicated to learn.  But
Java programmers do learn them.  How about if we give them
additional rewards for having learned then?  Instead of asking
them to learn yet another sub-language (tuples-for-deconstructors)
that is completely different?

(Yes, I’m partial to DA/DU because those are my rules, for better
or worse.  Maybe Remi’s going to say something about a sunk cost
fallacy.  But I think the rules are useful and, with an IDE’s help,
intuitive.  And they can do more for us now.  Let’s double down
on them.)

So here’s a principle to try out:

The natural form of a multiple-value producing construct, in Java,
is a scope in which named/typed variables are in scope, are DU,
and must be DA before exit.

As a variation, the natural form of a transactional multiple-value
consuming-and-producing  construct, in Java, is a scope where
the values to be produced and consumed are both named/typed
variables (as above), and where if a name is to be produced and
consumed, it is a (mutable) DA value which is updated in the
scope, and if a name is to be consumed only it is an (immutable)
DA value, and otherwise the name to be produced only is DU
but must be DA at every (normal) block exit.

Regarding “block exit”:  A keyword like “return” (as in lambda)
or “yield” (as in e-switch) or “break” (as in s-switch) can provide
early return, exactly as today with constructors, and with suitable
DU/DA requirements on the variables.  (A value-producing return
(or yield) could in some cases be take to return a right-typed
bundle.  This might make sense, for example, with a constructor
for an inline type, which aborts the construction of the current
’this’ in favor of some replacement value.  This is illegitimate
for an identity class, but reasonable for an inline class.)

The above proposed patterns make sense both internally to
a class (e.g., as constructor bodies which can touch private names)
or externally (for untrusted code outside the capsule), as some sort
of with-block construction, or (today) lambdas.

Note that currently the natural form of a multiple-value consuming
construct in Java is a method or lambda body with formal parameter list
containing (wait for it) a set of named/typed variables in scope.
And/or a method body, where the named/type variables are instance
variables of the method’s class.  Or both (there are extra axes of
variation here).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200813/560dfdd6/attachment.htm>