2 ms·
In OCaml polymorphic variants solve the expression problem. Solutions to the expression problem in Haskell feel heavyweight. I've personally never encountered
by danharaj 10y ago
In OCaml polymorphic variants solve the expression problem.
Solutions to the expression problem in Haskell feel heavyweight. I've personally never encountered the problem in serious or production code. I cannot say whether that's because it isn't that important in practice or because its difficulty causes me to avoid designs that run into it.
- iheartmemcache 10y agoSlight digression but - PLT-Scheme (or Racket or whatever it's called now) : CL :: Haskell : OCaml Exploration of new ideas in Scheme and Haskell 'feel' more versatile. The representation of concepts are often more succinct and almost always have more of that that je ne sais quoi one gets from an elegant[1] math proof. In day-today coding with a team, I've used more of the CL/OCaml than the latter though for reasons I'm not entirely sure about. OCaml's modules are strictly more powerful than Hask98's type classes. [1] https://en.wikipedia.org/wiki/Mathematical_beauty https://en.wikipedia.org/wiki/Mathematical_beauty Didn't know this existed until just now, but glad Russell and Erdos are both mentioned in the first paragraph, and even more amused, considering their histories with formalism/ordered logic haha. Where's the Frege tragedy and the Wiggenstein Viennese fanboys?!
- jkarni 10y agoTo be fair, production (vs. library) code has to usually care much less about being extensible, since whoever needs to use it can also usually change it. In servant dealing with the expression problem (albeit in a pretty different way than the usual tagless final approach) was in my opinion a pretty big win - it means you can add terms the the API DSL as well as interpretations for it. I pretty regularly do the former when using it, and there are lots of libraries doing the latter. (Disclaimer: I'm one of the authors of servant.)