On Mar 10, 2021, at 11:10 AM, Guy Steele <guy.ste...@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-&.
