4 ms·
I do agree that the RealWorld stuff is there to enforce control flow, but that is exactly one of the things that we needed. I also realise that the modern GHC o
by adamretter 8y ago
I do agree that the RealWorld stuff is there to enforce control flow, but that is exactly one of the things that we needed. I also realise that the modern GHC optimizes such things away, so there is no RealWorld!
Regards implementation, as the type system available in XQuery is much more limited than that of Haskell, I had to choose some mechanism to represent an IO. Actually representing it as a state transforming function that operates on the RealWorld, as was done in the design of the IO Monad for Haskell, seems to work pretty well.
I tried to follow closely and adapt both:
1) Section 7.3 "Monadic I/O" from "A History of Haskell", Hudak, Hughes, Peyton Jones and Wadler 2007 - https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
2) Section 4 "Implementing monadic I/O" from "Imperative functional programming", Wadler and Peyton Jones 1992 - https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- lmm 8y agoI appreciate that your implementation follows the Haskell one. But the point of IO isn't the implementation, it's to make it easier to maintain code that interacts with the real world. That's the part that feels cargo-culty to me (having gone down the same path in Python once): if the type system can't actually enforce that your monads are composed correctly then you pay the same cost you would in Haskell but don't get the main benefit.