More specifically, how do I generate a new list of every Nth element from an existing infinite list?
E.g. if the list is [5, 3, 0, 1, 8, 0, 3, 4, 0, 93, 211, 0 ...]
then getting every 3rd element would result in this list [0,0,0,0,0 ...]
The ++ operator is the list concatenation operator which takes two lists as operands and "combine" them into a single list.
There is a function in Haskell that takes first n elements of user-supplied list, named take . The syntax is: function-name arg1 arg2 . So, take takes first 1000 elements from an infinite list of numbers from 0 to infinity.
My version using drop:
every n xs = case drop (n-1) xs of y : ys -> y : every n ys [] -> []
Edit: this also works for finite lists. For infinite lists only, Charles Stewart's solution is slightly shorter.
All the solutions using zip
and so on do tons of unnecessary allocations. As a functional programmer, you want to get into the habit of not allocating unless you really have to. Allocation is expensive, and compared to allocation, everything else is free. And allocation doesn't just show up in the "hot spots" you would find with a profiler; if you don't pay attention to allocation, it kills you everywhere.
Now I agree with the commentators that readability is the most important thing. Nobody wants to get wrong answers fast. But it happens very often in functional programming that there are multiple solutions, all about equally readable, some of which allocate and some of which do not. It's really important to build a habit of looking for those readable, non-allocating solutions.
You might think that the optimizer would get rid of allocations, but you'd only be half right. GHC, the world's best optimizing compiler for Haskell, does manage to avoid allocating a pair per element; it fuses the filter
-zip
composition into a foldr2
. The allocation of the list [1..]
remains. Now you might not think this is so bad, but stream fusion, which is GHC's current technology, is a somewhat fragile optimization. It's hard even for experts to predict exactly when it's going to work, just by looking at the code. The more general point is that when it comes to a critical property like allocation, you don't want to rely on a fancy optimizer whose results you can't predict. As long as you can write your code in an equally readable way, you're much better off never introducing those allocations.
For these reason I find Nefrubyr's solution using drop
to be by far the most compelling. The only values that are allocated are exactly those cons cells (with :
) that must be part of the final answer. Added to that, the use of drop
makes the solution more than just easy to read: it is crystal clear and obviously correct.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With