You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: