<@UE2FBFZFH> do you have a haskell -&gt; jvm bytec...
# arrow
j
@Jannis do you have a haskell -> jvm bytecode emitter?
j
There is eta-lang (ghc haskell compiler frontent + jvm bytecode backend), which is usable but discontinued afaik. If you need the jvm then I'd look at scala for equivalents or write a basic parser combinator library yourself (I'd love to help out, but I have some other projects atm that need to be done first). Basic parser combinators are not too hard, but require a bit of work.
Writing a parser lib is definitly on my todo list as that is something arrow will excel at, especially with implicit typeclass resolution and that is also immensly useful.
Also it's fun ^-^
j
kotlin is at a good centroid of many concerns, and imho there's no reason not to add the haskell killer features to the basic kotlin toolkit, whether by arrow or elsewhere.
hotspot, llvm, and js runtimes are at least adequate runtime targets with working sample code. these may need individual optimizations.
arrow has gone ahead with compiler extensions and bucked a few kotlin limitations to date.
j
haskell imo is far far superior to kotlin in most language related aspects. Arrow with the compiler plugin will catch up a tiny bit soon tho... GHC has a fair few backends it supports as well (native, llvm, js and soon web assembly, all with some limitations tho), but a missing jvm backend is quite annoying with some many existing projects being mostly jvm projects.
j
i don't know enough about the fundamental impedences to haskell but im of the opinion that some kotlinc extentions might enable hornclauses that define grammars that enable compile-time polymoprhic syntax changes to match a problem without divorcing the toolkit and runtime or forcing an external library binding both ways
i don't honestly know if Arrow is fundamentally moving toward that particular direction, but it seems to need some progress with similar factors to arrive at the FP features