I'd have to actually read the article to be sure, but I think I can answer both of these. --- Monadic reification has to do with the difficulty of getting a d

I'd have to actually read the article to be sure, but I think I can answer both of these. --- Monadic reification has to do with the difficulty of getting a data/AST representation of a monadic value. This seems possible since monads sort of by their virtue are about reifying some amount of a computation (i.e. the Free monad) but we get stuck because we can embed Haskell ("host" or "meta" language) functions into the Monads meaning that we cannot "see" into the binding structure there. If we want to use a monadic interface to create an AST fragment and then compile it later we get stuck. But, there are tricks people have discovered to get this done anyway: http://www.ittc.ku.edu/csdlblog/?p=88 http://www.ittc.ku.edu/csdlblog/?p=88 https://hackage.haskell.org/package/data-reify https://hackage.haskell.org/package/data-reify As noted in the second link, this essentially boils down to recovering observable sharing which violates purity, so it ends up being an IO operation. --- The second is similar to the first: we'd like to recover Boolean ASTs made of boolean operations on free variable markers so that we can reinterpret and compile them. The type of boolean ASTs is not `Bool` since Haskell have already normalized the language expression we're interested in. So we need to make another type `BoolEXP` which retains the whole operation so that we can get at it in a first-order/data-like way. --- Both of these are specific verbalizations of pretty common issues with embedded DSLs. They're not obvious or easy, but definitely standard challenges you'll face when making Haskell embedded DSLs.