Two new draft pattern matching JEPs

forax at univ-mlv.fr forax at univ-mlv.fr
Tue Mar 9 18:21:47 UTC 2021


> De: "John Rose" <john.r.rose at oracle.com>
> À: "Guy Steele" <guy.steele at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "Gavin Bierman"
> <gavin.bierman at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Samedi 6 Mars 2021 00:36:53
> Objet: Re: Two new draft pattern matching JEPs

> On Mar 5, 2021, at 2:41 PM, Guy Steele < [ mailto:guy.steele at oracle.com |
> guy.steele at oracle.com ] > wrote:

>>> because at the point where the pattern true(...) is evaluated, the Rectangle has
>>> already been destructured, obviously, we can ban this kind of patterns to try
>>> to conserve the left to right evaluation but the it will still leak in a
>>> debugger, you have access to the value of 'y' before the expression inside
>>> true() is called.

>> I would like to question your assertion

>> bindings are all populated at the same time by a deconstructor

>> Is this really necessarily true?

> Same question from me, and I hope it’s not true.

> And I see Brian has also piled on here!

>> I would have thought that the job of the deconstructor is to provide the values
>> for the bindings, and that int principle the values are then kept in anonymous
>> variables or locations while the subpatterns are processed, one by one, from
>> left to right. Because consider a more complex pattern:

> For records that is true. But eventually I would say that the
> job of the deconstructor is simply to provide some sort of
> bundle of bits which might need more “cooking” in order
> to unveil the components. Then, each occurrence of a
> binding variable or a sub-pattern triggers that cooking,
> but a don’t-care pattern (_ or …) does *not* trigger the
> cooking. Who cares when something is cooked? Well,
> if a component of an object is virtualized (NOT the case
> with records) then it might cost something to reify it.
> As a simple example, an array component might require
> that an underlying array be defensively copied.
> As a more subtle example, a RE-matching pattern
> might require a lot of additional “cooking” to
> reify the contents of an RE expression group.

> So, my model of a deconstructor, in general, is
> of one operation which produces a handle of
> some sort, plus N additional operations which
> optionally extract the N components. Or, almost
> equivalently, it is a configurable method
> which produces up to N values, based on how
> it is invoked. (There’s a job for indy here.)

> The body of a user-defined deconstructor could
> exercise all these degrees of freedom, if there
> were a way to “hook up” all of the out-vars,
> but also provide an “out-var-requested” flag
> for each one:

> class PairOfArrays {
> int[] a; int[] b;
> __Deconstructor(out int[] aa, out int[] bb) {
> if (aa requested) aa = a.clone();
> if (bb requested) bb = b.clone();
> } }

> Here, the set of requested variables in the pattern
> affects how much work the deconstructor does.

It seems to be an early over-optimization, i really hope that yoiu can keep the deconstructor protocol far simpler and for your example piggyback on frozen arrays instead. 

> — John

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210309/f838c9d1/attachment-0001.htm>


More information about the amber-spec-experts mailing list