And as a companion piece I really enjoyed Paul Sandoz's 'Code Reflection' talk https://www.youtube.com/watch?v=xbk9_6XA_IY, which considers how java code might understand java code. The sort of thing that enable pushing functions to SQL or GPUs for example.
Interesting, but I don't see how operating on the code model is going to be any easier than working on the AST. It seems much more hard to reason about many transformations as compared to manipulating the AST. I do hope they take inspiration from scala and rust macros
Well currently you can't get at the AST, only (with some hairy code) bytecode. (The use cases are post-compilation)
But suppose this work did enable that. What Paul is saying is that there are intermediate representations between bytecode and AST that are more helpful for these GPU / SQL / whatever runtime compilers. Representations that capture dataflows, for example. Chance are these compilers would transform an AST to something like this anyway.
Thanks, that makes sense. I think I approached more from the perspective of a library writer that doesn't want to delve into the depth of language to implement transformations/macros. However it does seem reasonable to have a variety of abstractions to be able to express these transformations in a way closer to the target language
Why ironic? Java is a multi paradigm language (though obviously not at the same level as say C++). It has been getting "functional" features for a while now, including streaming libraries, pattern matching, immutable records, etc.
Because they have in the past declared "Java is not a functional language" and were hostile to the use of monads in the standard library. They are adding nice features, but the language will never be as clean and unified as Scala.
Monads don’t go by the name, they must satisfy the axioms. How many people do it right? Even in Haskell lots of folks forget to check the axioms. Also, monads are hard to compose. I think there’s no reason to be like Cats or Arrow. It’s all already there, the mental shift is minimal in my opinion.
"Monads don't compose" just means you should choose a single monad for most of your functions; in Scala that is usually Future, Either, Try, IO or ZIO. There are conversion methods between the most common monads.
Scala monads are fantastic IMO; Either-based programming is simple and eliminates tons of boilerplate. So is Cats, although the learning curve is steep.
Edit to add: slides here https://cr.openjdk.org/~psandoz/conferences/2023-JVMLS/Code-...