[HN Gopher] Effect Cases in Switch
       ___________________________________________________________________
        
       Effect Cases in Switch
        
       Author : vips7L
       Score  : 38 points
       Date   : 2023-12-14 15:45 UTC (7 hours ago)
        
 (HTM) web link (mail.openjdk.org)
 (TXT) w3m dump (mail.openjdk.org)
        
       | hencq wrote:
       | Obviously this is still an early proposal that might not go
       | anywhere, but I find it interesting to see how more and more
       | functional programming constructs are creeping into Java. Who
       | knows if this makes it in, next they make exceptions resumable
       | and they go all the way to typed effects.
        
         | halfmatthalfcat wrote:
         | Java becoming Scala gets more real everyday.
        
           | 082349872349872 wrote:
           | It's the language Hilbert Hotel: when Java becomes Scala,
           | Scala can become ScalaZ, and ScalaZ becomes... (idk, some
           | sort of theorem prover language?)
        
           | vips7L wrote:
           | Scala but with way less foot-guns.
        
             | kelnos wrote:
             | True, but also a weaker type system, which is a shame.
        
         | pdpi wrote:
         | Python has been getting a bunch of similar features too.
         | ADTs+Pattern Matching form an incredibly powerful pair of
         | features that leads to code that is both concise and easy to
         | read, so it doesn't surprise me that it's getting retrofitted
         | into all sorts of languages.
        
         | trealira wrote:
         | This doesn't necessarily seem like functional programming
         | (although there's nothing wrong with functional programming).
         | It makes sense to unify switch and try-catch statements,
         | because they're both meant for selecting a path based on the
         | outcome of the selector expression (as the proposal says). It
         | would make sense for other languages with exceptions, like C++,
         | to adopt something like this, IMO.
         | 
         | > Who knows if this makes it in, next they make exceptions
         | resumable and they go all the way to typed effects.
         | 
         | You don't necessarily need that for resumable exceptions.
         | Common Lisp and PL/I got it a long time ago, although PL/I
         | isn't really in use anymore AFAIK.
         | 
         | Apparently, resumable exceptions used to be more commonly
         | accepted, and then they were rejected in the 1980s[1]:
         | 
         | > Originally, software exception handling included both
         | resumable exceptions (resumption semantics), like most hardware
         | exceptions, and non-resumable exceptions (termination
         | semantics). However, resumption semantics were considered
         | ineffective in practice in the 1970s and 1980s (see C++
         | standardization discussion, quoted below) and are no longer in
         | common use, though provided by programming languages like
         | Common Lisp, Dylan and PL/I.
         | 
         | I wasn't around then, which is why I say "apparently."
         | 
         | [1]: https://learn.saylor.org/mod/page/view.php?id=33094
        
       | bruce343434 wrote:
       | > (I realize that this may elicit strong reactions from some, but
       | please give it some careful thought before giving voice to those
       | reactions.)
       | 
       | Really? Over a language feature proposal? That would make it more
       | expressive?
        
         | DaveSchmindel wrote:
         | I imagine that many suggestions for prominent open source
         | projects, let alone a widely adopted language, turn into forums
         | similar to small town town-hall meetings.
         | 
         | There are probably a number of people of different walks of
         | life and usage of the lang that voice opinions regardless of
         | their relevance or significance in modern adoption of the lang.
        
           | vips7L wrote:
           | There's already been strong reactions by some in the Java
           | subreddit. A lot have bike shedding over syntax and some just
           | don't like the idea of handling exceptions this way.
        
             | DaveSchmindel wrote:
             | TIL about bikeshedding, thank you
             | @[vips7L](https://news.ycombinator.com/user?id=vips7L).
        
         | wavemode wrote:
         | There is nothing programmers get more fiery about than language
         | syntax. Nothing.
         | 
         | (Editors are a close second, though those holy wars are cooling
         | over time as people move away from coding in the terminal.)
        
       | mjcohen wrote:
       | A comment about ternarys:
       | 
       | Nested ternarys can be quite readable if they are formatted like
       | nested if-then-elses.
       | 
       | Here's an example from some awk code I wrote about 15 years ago.
       | vval = ((k > 1 \              ? substr(vval, 1, k-1) \
       | : "" \              ) \             substr(vv, length(vpfx)+1, 1)
       | \             vvn \             (k1 <= length(vval) \
       | ? substr(vval, k1) \              : "" \              ) \
       | );
       | 
       | Well, at least I find it readable.
        
         | frodowtf wrote:
         | Well, I don't.
        
         | tonyg wrote:
         | Yep. Further, ternaries are to cond as switch is to pattern
         | matching. Ternaries can be used to give a chain of boolean
         | expression decisions:                   a ? b :         c ? d :
         | e ? f :         g
         | 
         | which switch isn't so tidy for.
        
           | o11c wrote:
           | Unless, of course, you find yourself in one of the languages
           | with broken associativity or precedence.
           | 
           | `? :` has to be right-associative, and should have the lowest
           | precedence of any "normal" expression (only assignment and
           | comma expressions are lower). Note however that the middle
           | expression does not care about associativity, though
           | readability suffers if it has a lower precedence than the
           | ternary itself (a ? b = c : d).
           | 
           | As far as prettified indentation goes:
           | 
           | * if any argument is itself a ternary, force a break before
           | it
           | 
           | * if you have to break after `?`, indent
           | 
           | * if you have to break after `:`, indent unless the following
           | is a ternary
           | 
           | **
           | 
           | Note also that logical if-then-else is not actually the only
           | kind of ternary expression; it's just the only one that C
           | exposes. Common other ternary expressions in some contexts
           | include: bitwise if-then-else (aka select - note that the
           | famous bithacks page lies about xor being cheaper, since it
           | forgets that andnot is a primitive), modular exponentiation,
           | fused multiply-add, bitsearch (unless your type system can
           | supply the needle width), various "foo and right shift" that
           | would otherwise return more than a register (foo = multiply,
           | interleave, lcm, pow) and "foo and left shift" that would
           | return a fraction (foo = div, sqrt, cbrt). Passing in a
           | rounding mode or something can also add an argument to many
           | ops.
        
         | nikita2206 wrote:
         | People might not agree with you because they would be looking
         | for a nested ternary and your example only has two adjacent
         | ternaries.
        
         | dissident_coder wrote:
         | this is something that I would categorize under "horrific"
        
           | metadat wrote:
           | It looks like a dialect of chicken scratch.
           | 
           | https://www.whinycat.com/cdn/shop/products/chicken_scratch.j.
           | ..
        
       | ubertaco wrote:
       | >Based on some inspiration from OCaml...
       | 
       | My dream of getting to write more-OCaml-esque code at my day job
       | continues to flourish. I'm glad bright minds in language design
       | for the "majority" languages are looking to the wisdom found in
       | more-niche languages.
        
       | layer8 wrote:
       | Java seems to be slowly drifting out of the sweet spot between
       | "too basic" and "too complex".
        
         | DarkNova6 wrote:
         | What gives you this impression? I think all recent advances
         | have been very expressive while keeping readability high and
         | syntax complexity low.
        
       | frou_dh wrote:
       | Inspired by OCaml? That rings a bell.
       | 
       | How's this for something pulled from the archives... when I was
       | studying OCaml I saved a link to the presentation where the
       | feature was introduced into that language :)
       | https://youtu.be/DMzZy1bqj6Q?t=45
        
       | cies wrote:
       | I use Kotlin now. Java is merely the reason JVM starts with a
       | "J".
       | 
       | Converting 250kLOC was quite doable. Team couldn't be happier.
        
       | kelnos wrote:
       | I do in general like all the nice improvements they've been
       | making to Java over time (as someone who loved Scala back in 2015
       | or so). But this is silly; they should introduce a sealed `Try`
       | type like Scala has (or, well, just steal the version from the
       | Java "vavr" library), with `Success`/`Failure` record
       | implementations, and then you can destructure in the switch
       | statement. So something like https://java.godbolt.org/z/dh5ebPfeq
       | 
       | The benefit there is that it doesn't require any changes to
       | language or syntax. Hell, you can even use vavr's `Try` and
       | achieve the same effect, though I guess you can't destructure in
       | the same way as it doesn't use record.
        
       ___________________________________________________________________
       (page generated 2023-12-14 23:01 UTC)