3 ms·
I think you want to replace the "$" with a ".". But either way, you haven't done the same thing as the GP. It's not actually clear what the GP's algorithm is s
by wyager 10y ago
I think you want to replace the "$" with a ".".
But either way, you haven't done the same thing as the GP. It's not actually clear what the GP's algorithm is supposed to do, and I made the same reading mistake at first as well.
> I tend to think that as the accumulation condition gets more complicated, the for loop begins to be the clearer choice
You can just use recursion. It's very easy to translate a loop into a tight tail-recursive function in Haskell. The generated assembly code usually looks about the same.
In the most extreme case, you can just do a loop inside the State monad, which allows you to get (better defined) imperative semantics without mutability (although the compiler will often generate mutable-equivalent assembly when it sees that doing so is safe).
> This can lead to a bunch of allocation overhead for the intermediate lists
Haskell uses list fusion so this usually isn't a concern.
I transliterated the OP's example in another comment. It's a pretty straightforward recursive function of type e.g. "Int -> ByteString -> Int". Substitute ByteString with whatever constant-lookup data structure you want.
- aduffy 10y agoWith Haskell this isn't an issue because lists are evaluated lazily, but what I was trying to get at and failed to make clear was that other languages which allow functional-like behavior can result in unnecessary allocation. For example in Python doing multiple maps/filters will allocate multiple lists unless you use the itertools versions in Python 2.7.
- sgk284 10y agoI think the proper answer here is that Python 2.x should be treated as legacy. Python 3.x defaults to generators for maps/filters by default.
- wyager 10y ago> With Haskell this isn't an issue because lists are evaluated lazily Even more than that, the compiler will actually do things like replace map f . map g with map (f . g) To eliminate unnecessary allocations.
- rubberstamp 10y agoThats great. My greatest petpeevee is having to keep in mind the language gotchas when all I want to do is get it done.
- Peaker 10y agoHaskell has far fewer correctness gotchas than other languages. They stuck to consistent, predictable behavior - even when it made things tedious for years until new techniques were discovered. Haskell does have performance gotchas, though.