Open mitchellwrosen opened 5 years ago
I also have my eye on language-elm
as a way of standardizing on the Elm AST (annoying that the elm compiler itself is not on Hackage). But for now, I've just implemented one-off data types for Elm declarations.
The separation of concerns is not obvious at all. The point of elm-bridge is that it will sync your Elm code with your aeson options, so unless you support this it will not work! OTOH, I would be very interested in some sort of pretty printer for types and functions in Elm. It is really annoying the compiler is not on hackage!
I've thrown together a library that just generates Elm types from Haskell ones:
https://github.com/mitchellwrosen/elm-codegen
Would you be interested in basing this library atop that one? If so, I can throw it up on Hackage and am willing to maintain it.
The main benefit here is separation of concerns (and maintenance) - after just extracting an Elm type from a Haskell one, there's more to do of course... how the Elm type should look (e.g. optionally turning records into type aliases or messing with record field names), pretty-printing, JSON encoder/decoder generation, etc.
Also, fwiw, my template haskell code does handle the "phantom type variable" case just fine, which I noticed is still an open ticket here.