6 ms·

Monads aren't ADTs in general. The authors of haskell-98-tutorial thought otherwise. btw, it is a good idea to reduce almost everything to the very basics - la

Monads aren't ADTs in general. The authors of haskell-98-tutorial thought otherwise. btw, it is a good idea to reduce almost everything to the very basics - lambdas and special forms - it makes everything clear, concise and compact. In terms of CS (not Math or any theory) Monad is an ADT. Period. "do" notation is just optional sugar. does GHC mix pure and impure code into a single .o?)

Peaker 13y ago
Where did the authors of haskell-98-tutorial say that monads are in general ADTs? Do you mean algebraic data types or abstract data types? Monads aren't necessarily either one. Particular instances of Monad (e.g: IO) are abstract data types. Many instances of monad are algebraic data types (e.g: []). But there are non-abstract-type monads (e.g: StateT) and non-algebraic-data-type monads (e.g: (->) r) > In terms of CS (not Math or any theory) Monad is an ADT Monad is a generalization, some of the special cases are ADTs, some aren't. > does GHC mix pure and impure code into a single .o Sure, though I'm not sure why the division into object files is relevant?
- deleted 13y ago
  [deleted]
- dschiptsov 13y ago
  They said it in a section which introduces monads. What do you mean by []? A list? Pair is a the very-very classic ADT - cons/car/cdr.) Because pure functional code could be executed in a different thread, paralleled, even spitted between different nodes.
  - tome 13y ago
    > They said it in a section which introduces monads. It would be helpful if you provided the exact quotation and reference.
    - dschiptsov 13y ago
      Section 7, paragraph 2. Haskell's IO system is built around a somewhat daunting mathematical foundation: the monad. ... Rather, monads are a conceptual structure into which I/O happens to fit. ... ... For now, we will avoid the term monad and concentrate on the use of I/O system. It's best to think of the I/O monad as simply an abstract data type. To those who still want to fight - ADT is a concept form an implementation realm, and the only way to implement a monad is to define an abstract data type. Your lovely algebraic types are.. guess what?)
      - Peaker 13y ago
        The IO monad (a particular instance) is an abstract data type (not an Algebraic data type, by the way). Other monads (e.g: the State monad from Control.Monad.Trans.State) are not abstract data types (or algebraic for that matter). Specifically, for something to be an "abstract data type", it must not expose its internal representation, but only relevant operations. IO is indeed such an abstract data type which happens to be a Monad instance. State and [] are monads that do expose their internal representation: ergo, they aren't abstract data types. You seem to be confusing algebraic and abstract data types (different things!) and taking a statement about a specific monad instance (IO) as if it was about the general concept of Monads (it's not).
  - Peaker 13y ago
    [] is a list, yes (not a pair). I explicitly mentioned it as an example of a monad which is an algebraic data type. Then I also mentioned (->) which isn't. Why does the fact that pure code can be executed in all those ways relate to the object files? Same object file can have code of both kinds, and different pieces of code within it can run in different ways/threads/etc.
    - deleted 13y ago
      [deleted]
    - dschiptsov 13y ago
      a List is a generalization of a Pair - it could be empty, while a Pair cannot (logically). Apart from that, a Non-empty List could be viewed as a self-referential (recursive) Pair or a chain of Pairs. So, technically, List is the same ADT as Pair (cond/car/cdr) plus explicit null? and list? functions. Yes, they could, but it is more reasonable to split the code, so you could dlload or statically link the pure code independently from unsafe code.
      - Peaker 13y ago
        A list is not a "generalization" of a pair. If anything that used something else was a "generalization" of that other thing, things would get confusing. Why is it more reasonable to split the code? You get the safety from the type-system, so you don't need extra splitting in obj files. Such splitting would complicate matters, and have no extra gain.
        dschiptsov 13y ago
        A list is not a "generalization" of a pair. - a lot of good people think otherwise: http://www.youtube.com/watch?v=QV0A_hFPCnw http://www.youtube.com/watch?v=QV0A_hFPCnw
        Peaker 13y ago
        Again, please mention a specific quote and time... Or do you expect me to invest 50 minutes finding that quote in there?

Peaker 13y ago

Where did the authors of haskell-98-tutorial say that monads are in general ADTs? Do you mean algebraic data types or abstract data types? Monads aren't necessarily either one. Particular instances of Monad (e.g: IO) are abstract data types. Many instances of monad are algebraic data types (e.g: []). But there are non-abstract-type monads (e.g: StateT) and non-algebraic-data-type monads (e.g: (->) r) > In terms of CS (not Math or any theory) Monad is an ADT Monad is a generalization, some of the special cases are ADTs, some aren't. > does GHC mix pure and impure code into a single .o Sure, though I'm not sure why the division into object files is relevant?

deleted 13y ago
[deleted]
dschiptsov 13y ago
They said it in a section which introduces monads. What do you mean by []? A list? Pair is a the very-very classic ADT - cons/car/cdr.) Because pure functional code could be executed in a different thread, paralleled, even spitted between different nodes.
- tome 13y ago
  > They said it in a section which introduces monads. It would be helpful if you provided the exact quotation and reference.
  - dschiptsov 13y ago
    Section 7, paragraph 2. Haskell's IO system is built around a somewhat daunting mathematical foundation: the monad. ... Rather, monads are a conceptual structure into which I/O happens to fit. ... ... For now, we will avoid the term monad and concentrate on the use of I/O system. It's best to think of the I/O monad as simply an abstract data type. To those who still want to fight - ADT is a concept form an implementation realm, and the only way to implement a monad is to define an abstract data type. Your lovely algebraic types are.. guess what?)
    - Peaker 13y ago
      The IO monad (a particular instance) is an abstract data type (not an Algebraic data type, by the way). Other monads (e.g: the State monad from Control.Monad.Trans.State) are not abstract data types (or algebraic for that matter). Specifically, for something to be an "abstract data type", it must not expose its internal representation, but only relevant operations. IO is indeed such an abstract data type which happens to be a Monad instance. State and [] are monads that do expose their internal representation: ergo, they aren't abstract data types. You seem to be confusing algebraic and abstract data types (different things!) and taking a statement about a specific monad instance (IO) as if it was about the general concept of Monads (it's not).
- Peaker 13y ago
  [] is a list, yes (not a pair). I explicitly mentioned it as an example of a monad which is an algebraic data type. Then I also mentioned (->) which isn't. Why does the fact that pure code can be executed in all those ways relate to the object files? Same object file can have code of both kinds, and different pieces of code within it can run in different ways/threads/etc.
  - deleted 13y ago
    [deleted]
  - dschiptsov 13y ago
    a List is a generalization of a Pair - it could be empty, while a Pair cannot (logically). Apart from that, a Non-empty List could be viewed as a self-referential (recursive) Pair or a chain of Pairs. So, technically, List is the same ADT as Pair (cond/car/cdr) plus explicit null? and list? functions. Yes, they could, but it is more reasonable to split the code, so you could dlload or statically link the pure code independently from unsafe code.
    - Peaker 13y ago
      A list is not a "generalization" of a pair. If anything that used something else was a "generalization" of that other thing, things would get confusing. Why is it more reasonable to split the code? You get the safety from the type-system, so you don't need extra splitting in obj files. Such splitting would complicate matters, and have no extra gain.
      - dschiptsov 13y ago
        A list is not a "generalization" of a pair. - a lot of good people think otherwise: http://www.youtube.com/watch?v=QV0A_hFPCnw http://www.youtube.com/watch?v=QV0A_hFPCnw
        Peaker 13y ago
        Again, please mention a specific quote and time... Or do you expect me to invest 50 minutes finding that quote in there?