Deconstructors a bit unintuitive?

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "John Hendrikx" <hjohn at xs4all.nl>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Thursday, September 22, 2022 4:28:25 PM
> Subject: Re: Deconstructors a bit unintuitive?

> On 9/22/2022 9:37 AM, John Hendrikx wrote:

>> I was reading [
>> https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md
>> |
>> https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md
>> ] and wished to give some feedback.
> I appreciate the feedback, but I'm going to ask you hold it for a few reasons:

> - This feature isn't really even really under discussion yet - the document
> shown was merely an illustrative sketch, and no substantive discussion has been
> had yet;
> - Your concerns are mostly with the illustrative example syntax shown in that
> document, which should not be taken as a serious proposal. (One of the trouble
> with such documents is that you have to show *something*, but then people will
> immediately assume "so this is the final syntax" and commence arguing.)
> - The syntax concerns of deconstructors are coupled to more complex forms of
> pattern declaration, whose considerations and requirements may not yet be
> obvious and are not considered in that document.

> Basically, that document was attempting to illustrate the dualities between
> constructors and deconstructors, and didn't want to try to do more, but of
> course it is hard to visualize these things without a code sketch, and hard to
> treat such code sketches for what they are.

> I'll try to speak a bit to your general conceptual issues, bearing in mind the
> constraints of the above.

>> I find the (possible) approach presented for deconstructors a bit counter
>> intuitive, where parameters are treated as outputs for deconstructors. I think
>> that an approach where it more closely matches the standard pattern of
>> "<output> <function> <input>" would be more intuitive.

> To some degree, declaring patterns is going to be uncomfortable somehow no
> matter what we do. Its not obvious from the examples in the document, which
> were focused on a different aspect, but in generality patterns can have full
> argument lists of *both* input parameters and output bindings. They simply will
> not fit cleanly in the "N in, one out" model of methods. So there is going to
> be something counterintuitive somewhere, and the solution is likely to involve
> some degree of extending our mental model about executable members.

>> The current approach instead looks very much like parameters that are passed by
>> reference (pointers to those parameters) but without any indication (like "&"
>> or "ref"), aside from the deconstructor keyword, that this is the case:

>> public deconstructor Point(int x, int y) { x = this.x; y= this.y; }

>> I find this quite jarring; overwriting (what looks like) a parameter with a new
>> value never affected anything beyond the scope of the function. I realize that
>> changing objects has effects beyond the function scope, but this was never the
>> case for the parameter variables themselves.

> Your point is correct that the *position* of the binding list in the declaration
> is unnecessarily confusing, because it is where you would expect the parameters
> to be. As it turns out, there are other reasons why this particular positioning
> has issues, but I'm not going to repeat the mistake by showing a more recent
> sketch, so we'll just have to wait for a "serious" proposal before continuing
> the discussion.

>> I suppose this has been considered and discussed before, and introducing
>> something as generic as multiple return values in order to support
>> deconstructors in this way may be a bridge too far, but perhaps my feelings on
>> this topic may still contribute something to this feature.

> The "multiple return" interpretation is indeed one that springs easily to mind
> as a first thought, but it turns out to run out of gas before it gets where it
> needs to go. (See "Isn't this just multiple return" in [
> https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md
> |
> https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md
> ] for one of the multiple reasons why I don't want to go in this direction.)

> The issues outlined in that section illustrate where this approach runs out of
> gas: it would only work with unconditional patterns. Deconstructors are
> unconditional, but it is a short hop to patterns that are the dual of, say,
> `Optional.of(v)`, and then treating destructuring as merely "invoking a
> multiple return method" falls apart because it has no way to express the
> conditionality. And having a separate syntax for "invoking" conditional and
> unconditional patterns carries its own problems.
With conditionality also comes exhaustivity, we need a way to declare that a group of pattern methods are exhaustive, e.g. the pattern methods Optional.of() and Optional.empty() are exhaustive. 
Because exhaustivity implies conditionnality, in term of syntax we may not need to express conditionality, but only two separate concerns, exhaustivity (or not) and return types. 

I think fostering exhaustivity when describing pattern methods play well with the idea of data oriented programming. 

> Which brings us to my initial statement, which is that patterns are going to
> require extending our mental models about executable members. It is probably
> better to discuss what that model is first.
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220922/81ed145e/attachment-0001.htm>