4 ms·

What would do notation add to Java?

pharmakom 5y ago
There are lots of places where it can help, but to give one example consider the Java 8 Optional type. It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this. The language even provides a bind function, but no reasonable way to use it!
- Skinney 5y ago
  Excessive nesting? Optional supports both .map and .flatMap.
emptysea 5y ago
Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await [0]: https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/ [1]: https://zio.dev https://zio.dev
- kaba0 5y ago
  For the async use-case, “native do notation” will be superior in the form of Loom, that will transform virtual thread calls to non-blocking concurrency. As for others, without proper Monads, I doubt they would have much use.
mhh__ 5y ago
Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading, but you can't overload control flow. Therefore building the notions I wanted to in code was very painful without some kind of (equivalent notion to) do-notation.
- seanmcdirmid 5y ago
  Can you do something similar in Kotlin using this function scopes (that let you change the meaning of this in a lambda)? I’ve found those ok at defining EDSLs.
  - mhh__ 5y ago
    I've only ever done a hello world in Kotlin I'm afraid.
    - seanmcdirmid 5y ago
      You should check it out. Definitely not as expressive as Scala for expressing EDSLs, but it has a couple of features (scoped this for lambdas and extension functions/properties that can be injected into a lambda's namespace by a scoped this type) that you can get a lot of mileage out of.

There are lots of places where it can help, but to give one example consider the Java 8 Optional type. It’s great for avoiding nulls, but you get excessive nesting with many isPresent checks. Do notation can fix this. The language even provides a bind function, but no reasonable way to use it!

Skinney 5y ago
Excessive nesting? Optional supports both .map and .flatMap.

emptysea 5y ago

Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await [0]: https://typelevel.org/cats-effect/ https://typelevel.org/cats-effect/ [1]: https://zio.dev https://zio.dev

kaba0 5y ago
For the async use-case, “native do notation” will be superior in the form of Loom, that will transform virtual thread calls to non-blocking concurrency. As for others, without proper Monads, I doubt they would have much use.

mhh__ 5y ago

Not specifically for Java but I have found myself wanting do-notation in non-functional languages so that I can basically write a very expressive library while also forcing users of that library to go down my road i.e. I hacked around it in the end as I didn't have a do-like abstraction but I had (in-effect, it wasn't quite a DSL) written a DSL that represented certain constructs just fine using operator overloading, but you can't overload control flow. Therefore building the notions I wanted to in code was very painful without some kind of (equivalent notion to) do-notation.

seanmcdirmid 5y ago
Can you do something similar in Kotlin using this function scopes (that let you change the meaning of this in a lambda)? I’ve found those ok at defining EDSLs.
- mhh__ 5y ago
  I've only ever done a hello world in Kotlin I'm afraid.
  - seanmcdirmid 5y ago
    You should check it out. Definitely not as expressive as Scala for expressing EDSLs, but it has a couple of features (scoped this for lambdas and extension functions/properties that can be injected into a lambda's namespace by a scoped this type) that you can get a lot of mileage out of.