Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pattern Matching for Java

cr.openjdk.java.net

Post reply on HN
Print view View original

121–130 of 152 posts

Re: Pattern Matching for Java

#121

Post by lmm »

raspasov wrote: post #117
lmm wrote: post #89

Earlier quoted context omitted.

The problem with pattern matching as I've seen it implemented is that unsafe and safe pattern matching look exactly the same (even the exact same code line can be safe or unsafe depending on context). See the bottom of http://typelevel.org/blog/2014/11/10/why_is_adt_pattern_matc... . For this reason I tend to prefer explicit virtual methods even though they're more cumbersome.

The pattern matching I have in mind is very dynamic in nature and does not concern itself at all with some static notion the data that is being matched. Either there's a match, or there isn't. It's a very binary outcome.

That's not the important/valuable use case for what people normally refer to as "pattern matching".

Re: Pattern Matching for Java

#122

Post by [deleted] »

macca321 wrote: post #120
peeters wrote: post #11

IMO this is the biggest thing available to modern languages that Java is missing. I would absolutely love to see this, particularly pattern decomposition. I wonder if you could do it without something analogous to Scala's sealed classes though--you really want your type checker to be able to assert every match has considered every branch (without having to specify a "default" everywhere). That means you need to be ab…

I retrofitted F# style "discriminated unions" (which are basically sealed heirarchies) into C# by creating a series of generic types `OneOf ` which can hold exactly one value, Each type has a `.Match` and `.Switch` methods, in to which you have to pass lambdas to handle each case `.Match(Func `. I don't know if this would work in Java, given the generic type erasure, but it might... 1. https://github.com/mcintyre321/…

[deleted]

Re: Pattern Matching for Java

#123

Post by [deleted] »

macca321 wrote: post #120
peeters wrote: post #11

IMO this is the biggest thing available to modern languages that Java is missing. I would absolutely love to see this, particularly pattern decomposition. I wonder if you could do it without something analogous to Scala's sealed classes though--you really want your type checker to be able to assert every match has considered every branch (without having to specify a "default" everywhere). That means you need to be ab…

I retrofitted F# style "discriminated unions" (which are basically sealed heirarchies) into C# by creating a series of generic types `OneOf ` which can hold exactly one value, Each type has a `.Match` and `.Switch` methods, in to which you have to pass lambdas to handle each case `.Match(Func `. I don't know if this would work in Java, given the generic type erasure, but it might... 1. https://github.com/mcintyre321/…

[deleted]

Re: Pattern Matching for Java

#124

Post by thinkmoore »

There is some very cool language design work from Chinawat Isradisaikul and Andrew C. Myers at Cornell on adding very powerful matching constructs to a Java-like language.

Paper: http://www.cs.cornell.edu/~chinawat/papers/pldi13-p343-israd... Slides: http://www.cs.cornell.edu/~chinawat/papers/chin-pldi13-slide...

Re: Pattern Matching for Java

#125

Post by tylerpachal »

mark242 wrote: post #60
taeric wrote: post #39

Earlier quoted context omitted.

This still seems a terrible example just to try and avoid naming an object. Isn't the comparison to: Object o = functionThatReturnsAnyVal(); if (o instanceof Integer) { Integer i = (Integer) o; if (i > 2) { System.out.println("Greater than 2."); } else { System.out.println("Less than or equal to 2."); } } else if (o instanceof String) { String s = (String) s; System.out.println("Hello, " + s); } I get that the case s…

In reality my function would rarely exist in the Scala world since having a weakly-typed return like that is cringeworthy to say the least. But it's better to see this in action with Scala options. val myOptionalVar: Option[String] = functionThatReturnsOption() myOptionalVar match { case Some(str) if str.length > 10 => System.out.println("This is a long string.") case Some(str) => System.out.println("This is a short…

I think this is less-rare than you think. In my Scala code, I have a lot of matching on weakly-typed values which come from parsing JSON objects (where I also deal with a lot of optional values).

Re: Pattern Matching for Java

#126

Post by raspasov »

lmm wrote: post #121
raspasov wrote: post #117

Earlier quoted context omitted.

The pattern matching I have in mind is very dynamic in nature and does not concern itself at all with some static notion the data that is being matched. Either there's a match, or there isn't. It's a very binary outcome.

That's not the important/valuable use case for what people normally refer to as "pattern matching".

I've recently found dynamic pattern matching pretty valuable to completely replace REST-like server-side APIs with a data-oriented API that gets pattern matched and dispatched based on the actual values and shapes of the data structure.

It helps almost completely avoid the /get/this /get/that /set/those explosion of API getters and setters that ultimately leads to very complex client logic that makes any notion of consistency at a distance very hard to reason about.

Re: Pattern Matching for Java

#127

Post by gjmacd »

Jeez, seems like overkill when you get that free in more modern of stacks. Move to Elixir. Pattern matching is done right and it's brilliantly designed. I understand that if you're having to maintain Java applications, but why anybody would stomach a NEW project on that behemoth is beyond me. I'm not just talking about performance, I'm talking about object topology BS, complicated libraries, etc. Java (for me now) seems like it's bolted on to the Web and simply doesn't have it's place as a Web stack. My opinion of course but with the great amount of stacks out there -- I don't get the fascination.

Re: Pattern Matching for Java

#128

Post by pyrale »

flavor8 wrote: post #4

Any substantial differences from Scala's implementation? From what I remember of Odersky's book it seems very similar if not identical. (Which is fine - I'm all for Java incorporating the best parts of Scala.)

Caustic people may argue that Java already has the worst parts of Scala :p

Re: Pattern Matching for Java

#129

Post by chriswarbo »

chriswarbo wrote: post #111
jamesblonde wrote: post #103

Earlier quoted context omitted.

The move towards Interactive Applications has helped OO and scripting languages. There are still plenty of applications for functional programming in the most demanding of environments, for safety and high availability. However, most students are not good enough at math to learn functional programming concepts. Whether that's the teachers' fault or the students' fault or society's fault, I can't say. But if we paid p…

> However, most students are not good enough at math to learn functional programming concepts. I don't agree with this. Many programming concepts outside functional programming can be very hard to grasp, yet we expect students to pick them up, and we expect front-end Web devs to use (some of) them every day. Some examples off the top of my head: - Pointers (e.g. the many incompatible meanings of " " in C). - Classes…

Oops, I meant the incompatible meanings of the asterisk in C; HN swallowed it as markup, and emphasised the rest of the comment.

Re: Pattern Matching for Java

#130

Post by zastrowm »

lacampbell wrote: post #66
zastrowm wrote: post #63

Earlier quoted context omitted.

> A dynamic type is probably just implemented as a tagged bit of data, surely A dynamic "type" is really just `object` whose methods are looked up at run time. It's not tagged data at all. See [1] for more info, specifically the example(s) at the bottom, as the reflection code is what gets executed at run (albeit with caching so that methods aren't looked up all the time). `dynamic` is a complex feature that enables…

I am talking about what value you could pass into the multiple dispatch code in the article I linked to. I know you can cause run time type errors using dynamic in general, but in the code I linked it was very well contained and water tight. Dynamically typed languages usually represent objects as something like a struct with an int tag to represent the type, and a void pointer for its value. The actual reflection go…

> I am talking about what value you could pass into the multiple dispatch code in the article I linked to

Ah, I misunderstood the question. Yes, in that case it's fairly type-safe.

> The actual reflection going on in the code I posted for multiple dispatch would surely be nothing more than an int comparison

Is this based on gut reaction or are you talking about optimizations that `dynamic` performs? I ask because my understanding is that `dynamic` is like a really efficient reflection-emitter, that attempts to do at runtime the same thing that the compiler would do at compile time, but slower because it has to look stuff up via reflection.

From Eric Lippert [2]:

> The magic is: the compiler emits code that starts the C# compiler again at runtime. The runtime version of the compiler analyzes the call as though the compile-time types of all the objects had been their actual runtime types, generates an expression tree representing that call, compiles the expression tree, caches the delegate for next time, and runs the delegate.

[2]: http://stackoverflow.com/questions/10330805/c-sharp-multiple...

So maybe `dynamic` at runtime figures out that it can do a "a struct with an int tag to represent the type, and a void pointer for its value", but I wouldn't assume it does and from what I've read on it, I wouldn't think that it does.

Post reply on HN