Hello. from now on, i would like to provide regular updates about my project: documenting and improving cmm.
In the past few days, i have: 1. implemented the bones for a cmm ast serialization https://github.com/GunpowderGuy/cmm-documentation/blob/master/myproject/src/Main.hs 2. improved the writing / redaction on the cmm documentation i wrote that goes over how features are implemented https://github.com/GunpowderGuy/cmm-documentation/blob/master/Exploded_view.md To elaborate on those points: in that document, i want to explain for each feature: * how textual cmm code gets parsed (what parser code handles an example feature) * what part of the ast (haskell data type) handles that feature * what part of the pretty printer handles the ast feature about the cmm ast (de)serializer: i have been deriving generic for the cmm datatypes, and the aeson typeclasses for said types. i started doing so with the top level type the cmm parser outputs. when implementing fromjson, ghc complains about its subtypes not implementing fromjson. i implement fromjson for those. this has been going well, but now i hit a blocker. some of the types use type level features such as gadts, which prevent generic from being derived for them. there are many ways i could work around this. generic is used for automatically deriving serialization in aeson. i could implement the methods manually for gadts types and the like, but i would prefer not doing so since going the generic way allows me to easily add more (de)serialization formats. for example, i can use a non aeson framework with fewer dependencies and the instances will be derived from generic. i could support that and conditionally not use aeson. given that, i think i could manually write generic instances or use a workaround like this: ( https://hackage.haskell.org/package/kind-generics )
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-le...@haskell.org
