3 ms·

There is no overhead here. IO gets erased at compile-time in GHC, IO is kept abstract and interacted with via Functor/Applicative/Monad to cooperate with the li

There is no overhead here. IO gets erased at compile-time in GHC, IO is kept abstract and interacted with via Functor/Applicative/Monad to cooperate with the linearization. Monad was introduced to clean up the nesting and give it a nice syntax.

Dewie3 11y ago
I'm talking about the Monad style in general, with the do notation, closures and what have you. Typically such things add an interpretive overhead, in the same way that a formatting print function adds interpretive overhead unless it is implemented with a macro, some kind of metaprogramming technique to evaluate and inline the interpretive component, or other techniques. I've read that the monadic style in Haskell has this kind of overhead, which is further pronounced with monad stacks. Is that not the case?
- dllthomas 11y ago
  Speaking specifically to do notation, it has no impact on performance, being a purely syntactic transformation. I have heard that transformer stacks can add "wrapping/unwrapping overhead", but haven't looked at it in depth, most of my Haskell work not being terribly performance sensitive at that scale.
  - Dewie3 11y ago
    > Speaking specifically to do notation, it has no impact on performance, being a purely syntactic transformation. Of for Christ's sake, I of course mean the bind and the `>>` and whatever that it desugars to. You aren't adding something to the discussion. But thanks for reminding me that syntactic sugar has no runtime overhead... There seems to be a lot of potential for removing all cruft that comes from things like this, namely to remove the interpretive overhead. I used to think of "interpretive" as only those language executioners. But I suspect that a lot of constructs have them. Macros, or whatever mechanism you use to avoid that overhead should maybe have a place in languages that try to both be high-level and to be somewhat high performing.
    - dllthomas 11y ago
      "Of for Christ's sake, I of course mean the bind and the `>>` and whatever that it desugars to. You aren't adding something to the discussion. But thanks for reminding me that syntactic sugar has no runtime overhead..." You asked a question, I addressed the parts of it I could address. I don't have a full picture of what you do and don't understand, to reference in pruning my response. If you're aware that do-notation is syntactic sugar then of course I would expect you to be aware that it has no runtime overhead - but I regularly encounter people confused on that first point. My comment adds to the discussion if you're one of those confused people (which apparently you aren't), if one of those people winds up reading the thread, and also to clarify your question for anyone else interested in answering. My answer wasn't intended to be derisive in any way - I don't appreciate abuse in response.
  - coolsunglasses 11y ago
    >I have heard that transformer stacks can add "wrapping/unwrapping overhead", mtl-style final encodings can help here, from what I understand. `mtl` has won any benchmark I've seen, over concrete transformer stacks, Free, and others.

Dewie3 11y ago

I'm talking about the Monad style in general, with the do notation, closures and what have you. Typically such things add an interpretive overhead, in the same way that a formatting print function adds interpretive overhead unless it is implemented with a macro, some kind of metaprogramming technique to evaluate and inline the interpretive component, or other techniques. I've read that the monadic style in Haskell has this kind of overhead, which is further pronounced with monad stacks. Is that not the case?

dllthomas 11y ago
Speaking specifically to do notation, it has no impact on performance, being a purely syntactic transformation. I have heard that transformer stacks can add "wrapping/unwrapping overhead", but haven't looked at it in depth, most of my Haskell work not being terribly performance sensitive at that scale.
- Dewie3 11y ago
  > Speaking specifically to do notation, it has no impact on performance, being a purely syntactic transformation. Of for Christ's sake, I of course mean the bind and the `>>` and whatever that it desugars to. You aren't adding something to the discussion. But thanks for reminding me that syntactic sugar has no runtime overhead... There seems to be a lot of potential for removing all cruft that comes from things like this, namely to remove the interpretive overhead. I used to think of "interpretive" as only those language executioners. But I suspect that a lot of constructs have them. Macros, or whatever mechanism you use to avoid that overhead should maybe have a place in languages that try to both be high-level and to be somewhat high performing.
  - dllthomas 11y ago
    "Of for Christ's sake, I of course mean the bind and the `>>` and whatever that it desugars to. You aren't adding something to the discussion. But thanks for reminding me that syntactic sugar has no runtime overhead..." You asked a question, I addressed the parts of it I could address. I don't have a full picture of what you do and don't understand, to reference in pruning my response. If you're aware that do-notation is syntactic sugar then of course I would expect you to be aware that it has no runtime overhead - but I regularly encounter people confused on that first point. My comment adds to the discussion if you're one of those confused people (which apparently you aren't), if one of those people winds up reading the thread, and also to clarify your question for anyone else interested in answering. My answer wasn't intended to be derisive in any way - I don't appreciate abuse in response.
- coolsunglasses 11y ago
  >I have heard that transformer stacks can add "wrapping/unwrapping overhead", mtl-style final encodings can help here, from what I understand. `mtl` has won any benchmark I've seen, over concrete transformer stacks, Free, and others.