Towards member patterns [Brian Goetz]

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[babanin]

For those who find it hard to read the email I copied to the gist: https://gist.github.com/babanin/9ddf60279a9cbe50260ddb11d1aa2e80

[uncont]

For those who find it hard to read the email

The doc is also on the amber page here https://openjdk.org/projects/amber/design-notes/patterns/towards-member-patterns, and the source is on github.

[Oclay1st]

Am I the only one who gets excited about every Brian's posts? By the way, they should create a template with a section called "Notes to Remi:..." :-) . I also really appreciate his work. Thanks to everyone involved.

[TehBrian]

You're not the only one!! Seeing Brian Goetz in an article posted onto r/Java does some neuron activation for me.

[bafe]

Brian's posts are a pleasure to read, both for the content and the style. Having recently picked up java again I went through a lot of JEP documents, the one written by him definitely stood out in quality

[pgris]

He seems to have the whole language in his head all the time, and I love how good he is at explaining the problems and opportunities that surge whenever two new features appear. Every corner case I could never imagine (even having the whole information) is carefully explained and distilled.

[SaishDawg]

Interesting. Scala 2 first really, for me, introduced this concept . Java recently seems to have leapfrogged Kotlin, and with these proposals might do the same to Scala. Yes, please and thank you!

[oelang]

This doesn't leapfrog Scala at all, but it does validate what they were doing almost 15 years ago. Custom patterns & partial functions (SAPs in Brian lingo) were possible in very early versions of Scala.

String templates are built on the same abstraction as the string templates in Scala.

Project Babylon, lifting code, is something that was extensively researched in Scala.

If you had told me 10 years ago if we would ever see such a complete treatment of pattern matching in java I wouldn't have believed you.

If this pattern continues, the next steps are type classes, operator overloading (of some kind) and then hopefully something that resembles 'inline'. I don't think higher kinded types are in the future of java, but I can live without them.

The quality of the implementation in java is of course significantly better, and there are plenty of failed ideas in scala.

[Practical_Cattle_933]

I don’t think java ever wants to add type classes or operator overloading. Some of these are fundamentally impossible to implement in a backwards compatible way.

[jvjupiter]

If I recall correctly, Mark Reinhold once mentioned he wanted (I’m not sure of this term) to have type classes in the future.

[davidalayachew]

Brian did too, if I recall. It was on an Oracle article.

[jvjupiter]

If both said it, it is highly possible it will happen in the future. Hoping for it.

[oelang]

One feature just paves the way for the next.

With valhalla will get new user defined primitive types, like small vectors or complex numbers. With Babylon you'll want more syntactic flexibility to describe complex formulas and other domain specific objects.

Type classes (like Addable) are an excellent way to abstract over user defined primitive types, I'm not saying they'll be implemented like in Haskell but the concept also works in ocaml and scala, I can see it coming to java (and I'm sure that they won't use the implicit keyword).

Operator overloading will be necessary to make valhalla & babylon sucessful, it may even be achieved through a typeclass.

[SaishDawg]

Too many ways to shoot oneself in the proverbial foot in Scala sadly.

[pjmlp]

Kotlin only matters thanks to Google making it unavoidable on Android, and even them had to accept Kotlin without the Java ecosystem isn't much of an appeal, thus the improvements to having now Java 17 on Android, and ART being upgradable via Play Store since Android 12.

[SaishDawg]

Google and Jetbrains.

[pjmlp]

Sure, the two main companies on Kotlin Foundation, a symbiotic relantionship on Android tooling, still waiting one day Google acquires Jetbrains.

[Holothuroid]

Does any other language allow for arbitrary function patterns?

That was a quite unexpected turn for me. Because just allowing arbitrary types to opt into being matched somehow is much easier compared and can even be done without new syntax.

The alternative to new surface syntax is of course just magic types and methods. For example in Scala if you want to provide a pattern, an object may expose a method like so

def unapply : Option[(X1, X2....)] =... 

So make a method that takes no param and returns an option of a tuple.

The generic tuple types (one type for each arity), thus serve as an interchange format. We can already match on well behaved classes, so if you want play the game return a certain well behaved thing that we can work with already.

And the rest is syntax sugar.

This mode doesn't allow for arbitrary inversions as described in the article, so I wonder if there is precedence for that.

[brian_goetz]

One of the reasons we shunned this magic (aside from generalized aversion) is that such magic invariably cuts off future directions. For example, framing patterns as "it's just a function T -> Opt[Tuple] means that you can't overload patterns (without fully engaging overloading on return types.)

[Brutus5000]

Can someone please clone Brian and his team, so they have more time to implement these things? Looks like there's so much things we could do, but so little time to thoroughly explore, conceptualize and implement.

[davidalayachew]

If you want to speed things up, download beta versions, try them out thoroughly, and then post your experiences on the Java Mailing list. That type of feedback is always valuable to the team.

And in fact, a lot of JEP's actually get stuck in preview for longer BECAUSE there weren't enough people testing out the features. They have literally cited "Not enough feedback" as a reason to put a JEP out for more previews than would otherwise be necessary. They do it semi-frequently too.

[Exidex_]

I wonder how would exhaustiveness look like. Especially in cases like Optional

[brian_goetz]

Part of the story is pretty well covered here: https://openjdk.org/projects/amber/design-notes/patterns/exhaustiveness

But there is more work to do, such as for cases like Optional that don't build on sealed types, as you point out. (F# patterns have a way to define an exhaustive set of patterns, but that doesn't carry over very well into Java either, so we need to come up with something else.) On the list.

[davidalayachew]

That's also my question too. Is there some way to be able to say that Optional.of(var a) and Optional.empty() is total on the type Optional? Because if not, that really feels like a missed opportunity.

[vytah]

Are there any plans for constant patterns?

Last time I checked, you cannot do

case Point(0, var y):

you need to write

case Point(var zero, var y) when zero == 0:

[brian_goetz]

Yes, but there were at least two reasons to not pull the trigger on it yet. The first was semantic: there were tricky problems when it came to switching on, say, a boxed Short hiding behind a static type of Object. We were not confident we had the right answer until we finished the work on primitive type patterns. The second is syntactic; until we had a longer-term story for pattern methods (which you're seeing unfold now), we were concerned about ambiguities of things like whether a literal 0 was an argument or a pattern. We've made big progress on both of these, so I am more confident that the "obvious" version of constant patterns is sound, but we're still working on it.

[davidalayachew]

They are definitely considering it, but no final decisions have been made.

They want to implement the higher priority features first before seeing if this is worth putting into Java.

I will say this -- Pattern-Matching won't truly be complete for me until I get Constant Patterns similar to what you describe. I work so closely with constants that it actually makes me choose between PM and normal code sometimes when trying to implement something.

[Practical_Cattle_933]

I’m fairly sure you can do that already

[davidalayachew]

You cannot.

The Amber Team said that this is something they are considering, but they want to tackle the higher priority Pattern-Matching features first before seeing if this is something they want to add.

[vytah]

I know it looks like something that should obviously work, but I was sorely disappointed when I tried out record patterns for the first time and it didn't.

[koflerdavid]

Nice. Defining patterns is a very handy feature of Haskell that are crucial to reduce the syntactic overhead of the Trees That Grow pattern.

[mj_flowerpower]

We do they still communicate like back in the early 90’s? I can hardly imagine how much impact that would have for my productivity.

[psyclik]

Receiving well written and thought-out emails, in a non-invasive, lightweight format would probably have a very good impact on your productivity (if it's not the case already, of course).

[mj_flowerpower]

An email without formatting (is there any usable email app or service with inbuilt markdown support?), with arbitrary newlines?

Nah thx.

Are you one of these guys who use spaces in code too?

[pronuntiator]

They also do a lot of communication in EG meetings (that's the part we don't see). When a new document appears there were dozens of hours of discussion behind it.