[External] : Re: Guards redux

[John Rose]

On Mar 10, 2021, at 11:10 AM, Guy Steele <guy.steele at oracle.com> wrote:
> 
> But in principle it does matter for patterns, because while patterns arguably do not involve _evaluation_, they most certainly involve _execution_ of possibly user-written code.  If side effects can occur, the distinction arguably matters, and this is worth recognizing as we debate the design.

I don’t think user-written patterns can reliably exclude
side effects, and I think in some cases they will be useful
(to accumulate some sort of “log” on the side of matching
activity, perhaps to support backtracking).

So let’s say that one way or another we have to specify
ordering of side effects patterns.  (Eww:  What about
class loading side effects for resolved class names?
Do we have to package type names in thunks for
the pattern runtime?  Please, no.)

Given nested patterns P(Q,R), if P fails then there’s no way
to execute Q.  If Q fails there’s no benefit to executing R,
although that would be possible to more closely emulate
unconditional evaluation of function parameters.  Is
there any reason to do this?  I think not.  And then
P(Q & R) also has no reason to execute R if Q fails.

As I said to Remi, importing unconditional evaluation
rules from expressions into patterns makes no sense.

As Brian said, pattern-& is as similar to type-&
to expression-&.

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