3 ms·

I think you must be using a very non-standard definition of continuation. What exactly is your definition of continuation? In what way exactly does OCaml "hav

by tome 11y ago

I think you must be using a very non-standard definition of continuation. What exactly is your definition of continuation? In what way exactly does OCaml "have" them that Haskell doesn't?

pron 11y ago
You are right in that I am using the word continuation to highlight an important property of computational models (be they lambda calculus, Turing machines, or FSMs), namely the ability to stop and resume a computation. In imperative languages, subroutines are continuations in the sense that they can block and then be resumed (although only some languages have reified continuations that allow direct manipulation of the suspended continuation, as opposed to supporting just scheduling by the OS, although theoretically scheduling by the OS is enough to capture the expressive strength of continuations, albeit that it suffers from various performance problems). In Haskell, subroutines are functions and have no notion of "blocking". Because that notion is essential to computations, it is emulated in Haskell by composing functions together with monads rather than being supported "natively".
- 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 ago
      But 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 ago
        In 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 ago
        This 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).

by tome 11y ago

I think you must be using a very non-standard definition of continuation. What exactly is your definition of continuation? In what way exactly does OCaml "have" them that Haskell doesn't?

pron 11y ago

You are right in that I am using the word continuation to highlight an important property of computational models (be they lambda calculus, Turing machines, or FSMs), namely the ability to stop and resume a computation. In imperative languages, subroutines are continuations in the sense that they can block and then be resumed (although only some languages have reified continuations that allow direct manipulation of the suspended continuation, as opposed to supporting just scheduling by the OS, although theoretically scheduling by the OS is enough to capture the expressive strength of continuations, albeit that it suffers from various performance problems). In Haskell, subroutines are functions and have no notion of "blocking". Because that notion is essential to computations, it is emulated in Haskell by composing functions together with monads rather than being supported "natively".

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 ago
    But 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 ago
      In 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 ago
        This 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).