This is being extremely fun. Might switch from Control.Monad.Free to polysemy soon, but the code so
far is not too complicated. The goal here is to just build data structures. So interpreters will be mostly pure, without IO. pasted image cf. https://www.srid.ca/tidbits/dhall-toml-free-monad.html
The main problem with Dhall is ergonomics. I found myself to be no fan of meticulously writing syntax when all I want to do is add a link to my site. The other pain point was having to keep the Haskell type definition in sync with the Dhall type
I just find the free monad use to be more ergonomic. As shown in the screenshot, I can introduce a let binding in the middle of the data and then use it. Can't do this in Dhall.
This is being extremely fun. Might switch from Control.Monad.Free to polysemy soon, but the code so
far is not too complicated. The goal here is to just build data structures. So interpreters will be mostly pure, without IO. pasted image cf. https://www.srid.ca/tidbits/dhall-toml-free-monad.html
@Sridhar Ratnakumar Why was
dhall
problematic?From the post,
I just find the free monad use to be more ergonomic. As shown in the screenshot, I can introduce a let binding in the middle of the data and then use it. Can't do this in Dhall.
Oh, right, thanks!
My conclusion: dhall is for configuration, not data.
Configuration is sort of data too - I guess "non-repetitive data"
Both are structured, in my mind configuration is generally "small" compared to data that grows over time.