----- Original Message ----- > From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Sent: Sunday, April 17, 2022 4:58:26 PM > Subject: Re: Record pattern and side effects
> Yes, this is something we have to get “on the record”. > > Record patterns are a special case of deconstruction patterns; in general, we > will invoke the deconstructor (which is some sort of imperative code) as part > of the match, which may have side-effects or throw exceptions. With records, > we go right to the accessors, but its the same game, so I’ll just say “invoke > the deconstructor” to describe both. > > While we can do what we can to discourage side-effects in deconstructors, they > will happen. This raises all sorts of questions about what flexibility the > compiler has. > > Q: if we have > > case Foo(Bar(String s)): > case Foo(Bar(Integer i)): > > must we call the Foo and Bar deconstructors once, twice, or “dealer’s choice”? > (I know you like the trick of factoring a common head, and this is a good > trick, but it doesn’t answer the general question.) > > Q: To illustrate the limitations of the “common head” trick, if we have > > case Foo(P, Bar(String s)): > case Foo(Q, Bar(String s)): > > can we factor a common “tail”, where we invoke Foo and Bar just once, and then > use P and Q against the first binding? > > Q: What about reordering? If we have disjoint patterns, can we reorder: > > case Foo(Bar x): > case TypeDisjointWithFoo t: > case Foo(Baz x): > > into > > case Foo(Bar x): > case Foo(Baz x): > case TypeDisjointWithFoo t: > > and then fold the head, so we only invoke the Foo dtor once? > > Most of the papers about efficient pattern dispatch are relatively little help > on this front, because the come with the assumption of purity / > side-effect-freedom. But it seems obvious that if we were trying to optimize > dispatch, our cost model would be something like arithmetic op << type test << > dtor invocation, and so we’d want to optimize for minimizing dtor invocations > where we can. yes ! > > We’ve already asked one of the questions on side effects (though not sure we > agreed on the answer): what if the dtor throws? The working story is that the > exception is wrapped in a MatchException. (I know you don’t like this, but > let’s not rehash the same arguments.) Wrapping exceptions into a MatchException destroy any idea of refactoring from a cascade of if ... instanceof to a switch. I think refactoring is a use case we should support. Rémi
