3 ms·

And, for a completely different take on the subject, coroutines in Haskell: http://random.axman6.com/blog/?p=231 http://random.axman6.com/blog/?p=231 This is

by tikhonj 13y ago

And, for a completely different take on the subject, coroutines in Haskell: http://random.axman6.com/blog/?p=231 http://random.axman6.com/blog/?p=231 This is a nice article that explains how they work pretty well. It's very different from the C approach.

ginko 13y ago
Wouldn't you implement coroutines in Haskell by just generating a stream that is lazily evaluated? You can seed something like this with the iterate function for instance.
- ufo 13y ago
  One of the biggest reasons for using coroutines in Haskell is when you want to mix them with effects. For example, using lazy streams to do IO can lead to unpredictable resource usage so many people use coroutine libraries to do the IO in a more predictable manner (piper / conduits / io-streams / etc). Finally, while lazy streams go a long way, in terms of preventing the inversion of control that you usually need to use coroutines for, there are still some situations where coroutines are useful. For example try writing that consumer/producer example from the blog post he linked using only lazy streams...
- tel 13y ago
  Laziness is pretty implicit and while it enables all kinds of optimizations and reasoning it can be hard to understand the sequencing of effects. In particular, laziness and IO lead to code where handle opening and closure is difficult to understand. For instance lines :: IO [String] lines = withFile path $ \h -> hReadLines h will generate a lazy stream of strings in an IO action without actually reading those lines. You can either close the handle immediately and get a runtime error later when you force those lines OR leave it open and leak a file handle. Explicit coroutines help to ensure that you know exactly what to expect from effect interleaving. Mario Blazevic's article [0] is the quintessential treatment and forms the basis of the Pipes library today. [0] http://themonadreader.files.wordpress.com/2011/10/issue19.pdf http://themonadreader.files.wordpress.com/2011/10/issue19.pd...

by tikhonj 13y ago

ginko 13y ago

Wouldn't you implement coroutines in Haskell by just generating a stream that is lazily evaluated? You can seed something like this with the iterate function for instance.

ufo 13y ago
One of the biggest reasons for using coroutines in Haskell is when you want to mix them with effects. For example, using lazy streams to do IO can lead to unpredictable resource usage so many people use coroutine libraries to do the IO in a more predictable manner (piper / conduits / io-streams / etc). Finally, while lazy streams go a long way, in terms of preventing the inversion of control that you usually need to use coroutines for, there are still some situations where coroutines are useful. For example try writing that consumer/producer example from the blog post he linked using only lazy streams...
tel 13y ago
Laziness is pretty implicit and while it enables all kinds of optimizations and reasoning it can be hard to understand the sequencing of effects. In particular, laziness and IO lead to code where handle opening and closure is difficult to understand. For instance lines :: IO [String] lines = withFile path $ \h -> hReadLines h will generate a lazy stream of strings in an IO action without actually reading those lines. You can either close the handle immediately and get a runtime error later when you force those lines OR leave it open and leak a file handle. Explicit coroutines help to ensure that you know exactly what to expect from effect interleaving. Mario Blazevic's article [0] is the quintessential treatment and forms the basis of the Pipes library today. [0] http://themonadreader.files.wordpress.com/2011/10/issue19.pdf http://themonadreader.files.wordpress.com/2011/10/issue19.pd...