You should also talk about the last tier of the onion, the translation
strategy, because i may be wrong but ii think it will ripple to the two other
parts
(syntax and semantics).
Of course we have to talk about that, eventually. But there's a fine
line between "pick a model that can be efficiently translated" and "let
the translation-tail wag the model-dog." I would like to focus on the
object model first, and language model second, because a perfect
translation cannot save a bad design, but a good design can tolerate an
imperfect translation. (And it is not the case that we haven't been
thinking about translation as we go.)
At definition site, a pattern method is obviously a method and as Brian as
proposed earlier, bindings can be represented by a synthetic record as return
type, so something like
A synthetic record is obviously a good candidate, but not the only one.
For patterns with only one binding, no record "box" is needed; for some
patterns, having a synthetic "box" is just wasted motion (e.g., when the
object can be act as its own witness to its bindings.) So we should
keep synthetic records as possibilities, but we should not jump to this
as The Answer.
There's an older doc at:
https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-match-translation.md
that outlines an alternative strategy, which is potentially richer and
more efficient, and which was discussed at the JVMLS talk that year.
There, we have the method return not the matched values, but a Pattern
(which is a constant!), where a Pattern is a bundle of method handles.
The first method handle is a function from Target to Carrier (where
Carrier is a runtime implementation detail), where a null carrier means
"no match", and the other method handles are functions from Carrier to
Binding_i. These are all amenable to loading and composing via condy.
In this world, no classfile has to utter the name of the carrier class,
you just get it from one MH and feed it back to another.
But, I really would like to not get ahead of ourselves, so I would
rather not dive into this at the cost of distracting from the object
model decision. (Unless we're done with the object model decision?)
Given that we want to support overloading, the record corresponding to the
bindings as to be present as return type, so overloads are pattern methods with
the same name, may be the same parameters but a different return type.
I have proposed using the SF encoding of the erasure of the binding
descriptor as part of the name. But again, the important thing right
now is that there is a path, not nailing down what that path is.
if (carrier.match) {
var i = carrier.i;
...
}
Or:
var i = iComponentMH.invokeExact(carrier)
But, please let's table this until we are finished with the object model
discussion.
