3 ms·
OK, you are equating continuations with the ability to "block". Please explain how OCaml computations have a notion of "blocking".
by tome 11y ago
OK, you are equating continuations with the ability to "block". Please explain how OCaml computations have a notion of "blocking".
- pron 11y ago`input_line`
- tome 11y agoBut Haskell pure functions do "block" when they request memory from the allocator, for example. How do you distinguish these two kinds of blocking so you can claim that OCaml has it and Haskell doesn't.
- pron 11y agoIn the sense that this blocking can be fully or partially reified. I don't know much about OCaml's implementation of their lwt library, so I'll give an example from Java: In Java you can create a thread running a single subroutine, have that block by calling `park`, and then hold on to that blocked function in a form of a reified object (the thread), which you can resume at any time. This is not possible in Haskell, you cannot hold onto blocked subroutines (i.e. continuations); instead, you hold onto a chain of functions connected via a monad (or monads).
- tome 11y ago> This is not possible in Haskell, you cannot hold onto blocked subroutines (i.e. continuations); instead, you hold onto a chain of functions connected via a monad (or monads). I don't understand what this means, and I certainly don't understand the difference between the two things.
- pron 11y agoThis means that Haskell doesn't have an object representing a function blocked in mid-operation. The difference is one of abstraction (obviously all languages can ultimately express all computations), which affects composition and mental overhead. These, of course, are empirical effects, and so their merits cannot be justified on any theoretical grounds (theoretically, monads and continuations are the same).