3 ms·

I wrote about how Record Patterns along with Pattern Matching for Switch can be used to write things like Tree-Rewrite rules in AST analyzers/program optimizers

I wrote about how Record Patterns along with Pattern Matching for Switch can be used to write things like Tree-Rewrite rules in AST analyzers/program optimizers efficiently if anyone is curious: This is how Spark's optimizer Catalyst works in Scala https://gavinray97.github.io/blog/what-good-are-record-patterns https://gavinray97.github.io/blog/what-good-are-record-patte... Kind of wild to believe this is valid modern Java: return switch (expr) { // x + 0 = x case Add(Var(var name), Const(var value)) when value == 0 -> new Var(name); These two are my favorite new JDK features by miles, along with Sealed Types.

speed_spread 3y ago
It's just too bad they could not come up with an extended enum-as-tagged-union syntax. Using sealed classes for that pattern works but is still messy to write. It feels like writing enums with classes back in JDK 1.4 days.
- gavinray 3y ago
  I think "sealed interface" with implementations used by "records" gets you pretty close though right? This is usually what I do, something like: sealed interface Tree { record Leaf(int value) implements Tree {} record Node(Tree left, Tree right) implements Tree {} } var tree = new Tree.Node(new Tree.Leaf(1), new Tree.Leaf(2));
  - speed_spread 3y ago
    This is what I was talking about. With pattern matching I now expect this exact pattern will be 98% of usage of `sealed` anything. It would be nice to have some sugar like tagged-union Tree { Leaf(int value), Node(Tree left, Tree right) } I used `tagged-union` because for backward compat I think using `enum` would not be possible but really it could be anything.
    - kaba0 3y ago
      While I agree that some syntax sugar would be welcome here (AFAIK the best you can currently do is sealed interface Tree permits Tree.Leaf, Tree.Node { record Leaf(int value) extends Tree {} record Node(..) extends Tree {} } ), it is not too terrible. Also note that rust really mixed up the nomenclature here with their enums, these were known in every language previously simply as ADTs. It makes sense for these to not have identity, while java enums are always a single instance.
      - vips7L 3y ago
        You want `implements Tree` here or this won't compile.
derefr 3y ago
Do you know if these are just Java features, or if they're backed by new JVM bytecode intrinsics to ensure that these destructuring matches are able to be performed efficiently? (Think e.g. Erlang's recent "fused checks", where it can figure out whether something is an integer and whether it's non-negative using a single abstract-machine instruction.) That is, for languages that already have features like this (e.g. Scala), will those languages be getting any benefits as a byproduct of Java getting these features?
- gavinray 3y ago
  If you want a deep-dive into the bytecode, there's a great article at: https://medium.com/@nataliiadziubenko/java-20-pattern-matching-for-switch-whats-under-the-hood-223a109f5e2f https://medium.com/@nataliiadziubenko/java-20-pattern-matchi... The tl;dr = no new intrinsics (for now), it uses table-switches and invokedynamic
- PhilipRoman 3y ago
  I don't think you need any byte code intrinsics for pattern matching. Special cases aside, there is no generic efficient way to describe them. Java byte code is badly designed anyway so it's up to the VM compiler to do the heavy lifting.
  - whartung 3y ago
    This is actually a core concept of the Java runtime. The compilers and what not “know” about idiomatic Java. The trivial example is things like the getter/setter pattern so prevalent in Java. But the compiler doesn’t treat them as anything special, it’s just a method. But the runtime is well aware of this pattern, and what the resulting, straightforward byte code looks like, and can make optimization decisions from there. So where, perhaps, you may want try and write “clever” code to bend the compiler to your will, Java promotes “just write Java, no reason for the code to be tricky, let the compiler and VM implementations be tricky”.
    - avgcorrection 3y ago

speed_spread 3y ago

It's just too bad they could not come up with an extended enum-as-tagged-union syntax. Using sealed classes for that pattern works but is still messy to write. It feels like writing enums with classes back in JDK 1.4 days.

gavinray 3y ago
I think "sealed interface" with implementations used by "records" gets you pretty close though right? This is usually what I do, something like: sealed interface Tree { record Leaf(int value) implements Tree {} record Node(Tree left, Tree right) implements Tree {} } var tree = new Tree.Node(new Tree.Leaf(1), new Tree.Leaf(2));
- speed_spread 3y ago
  This is what I was talking about. With pattern matching I now expect this exact pattern will be 98% of usage of `sealed` anything. It would be nice to have some sugar like tagged-union Tree { Leaf(int value), Node(Tree left, Tree right) } I used `tagged-union` because for backward compat I think using `enum` would not be possible but really it could be anything.
  - kaba0 3y ago
    While I agree that some syntax sugar would be welcome here (AFAIK the best you can currently do is sealed interface Tree permits Tree.Leaf, Tree.Node { record Leaf(int value) extends Tree {} record Node(..) extends Tree {} } ), it is not too terrible. Also note that rust really mixed up the nomenclature here with their enums, these were known in every language previously simply as ADTs. It makes sense for these to not have identity, while java enums are always a single instance.
    - vips7L 3y ago
      You want `implements Tree` here or this won't compile.

derefr 3y ago

Do you know if these are just Java features, or if they're backed by new JVM bytecode intrinsics to ensure that these destructuring matches are able to be performed efficiently? (Think e.g. Erlang's recent "fused checks", where it can figure out whether something is an integer and whether it's non-negative using a single abstract-machine instruction.) That is, for languages that already have features like this (e.g. Scala), will those languages be getting any benefits as a byproduct of Java getting these features?

gavinray 3y ago
If you want a deep-dive into the bytecode, there's a great article at: https://medium.com/@nataliiadziubenko/java-20-pattern-matching-for-switch-whats-under-the-hood-223a109f5e2f https://medium.com/@nataliiadziubenko/java-20-pattern-matchi... The tl;dr = no new intrinsics (for now), it uses table-switches and invokedynamic
PhilipRoman 3y ago
I don't think you need any byte code intrinsics for pattern matching. Special cases aside, there is no generic efficient way to describe them. Java byte code is badly designed anyway so it's up to the VM compiler to do the heavy lifting.
- whartung 3y ago
  This is actually a core concept of the Java runtime. The compilers and what not “know” about idiomatic Java. The trivial example is things like the getter/setter pattern so prevalent in Java. But the compiler doesn’t treat them as anything special, it’s just a method. But the runtime is well aware of this pattern, and what the resulting, straightforward byte code looks like, and can make optimization decisions from there. So where, perhaps, you may want try and write “clever” code to bend the compiler to your will, Java promotes “just write Java, no reason for the code to be tricky, let the compiler and VM implementations be tricky”.
  - avgcorrection 3y ago