5 ms·
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 wan
by wenderen 11y 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.
- jsprogrammer 11y agoSorry, 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.