
Streams, Rulers and Laziness - wenderen
http://wenderen.github.io/Ruler-Series/
======
jfaucett
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/](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.

------
jsprogrammer
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?

~~~
wenderen
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.

~~~
jsprogrammer
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.

