Streams, Rulers and Laziness (opens in new tab)

(wenderen.github.io)

38 pointswenderen10y ago5 comments

5 comments

5 comments · 2 top-level

jsprogrammer10y ago· 3 in thread

This is cool. I wonder what the performance is on large streams?

>It doesn't work because we haven't defined interleaveStreams - which, for the sake of brevity, we will now refer to as iStr.

I much prefer `interleaveStreams` to `iStr`. I know Haskellers like to abbreviate things, but I think it just makes things harder to read for most people. What about using `interleave` and allowing the user to infer Streams from the function signature?

tikhonj10y ago

Yeah, `interleave` is the best. In a large program it would be located in a Stream module, making it clear from context, not just the type. If you were using it somewhere else, you would just import it qualified and use it as S.interleave or Stream.interleave.

At this point, I've come to believe that having too many functions with a set prefix or postfix is a code smell that's telling you to organize them into a module. Putting stream-related functions into a module has the same effect as naming them all with "-Stream" except it's actually part of the language and more flexible.

wenderenOP10y ago

I agree that `interleave` reads better than `iStr`. I've updated the post.

FWIW I wasn't really trying to name things in an idiomatic "Haskell" way, I just wanted a shorter name and `iStr` was the first thing that popped into my mind.

Regarding the performance issue, it's fast. As an example, running `take 10000000 $ streamToList ruler` at ghci forces Haskell to evaluate (and print) the first 10 million elements of the ruler sequence. On my machine I observed that the printing is the bottleneck. The computation of the next Integer in the series takes next to no time.

jsprogrammer10y ago

Sorry, I didn't mean to imply that the abbreviation was necessarily idiomatic Haskell. I've just seen so much Haskell code that contains abbreviations that it kind of turns me off from the language. :/

I really look the like of the code now :)

Printing will definitely be a bottleneck unfortunately, but I imagine the non-printing code will be quite fast. I'm mostly curious how it would compare to a well optimized C version.

Are you planning on developing on top of this anymore? One interesting use case I have for interleaved streams is for the streams to contain Promises (not sure what the equivalent is in Haskell) that must be run while only allowing a certain number of them to be run concurrently. Additionally handling multiple consumers (based on the value in the Stream), each with their own limit on how many Promises of that type can be run at a time. Adding time-based (say, a max of 10 items per second, per consumer, regardless of how fast the Promises finish). I'm sure this has been implemented many times, but it can be quite useful.

jfaucett10y ago

I discovered this course a while back and must say it is awesome. here's the link for those who missed it in the article's footer: http://www.seas.upenn.edu/~cis194/spring13/

For me personally, it is the best intro to haskell I could find, succint, to the point, and best of all are the assignments.

j / k navigate · click thread line to collapse