4 ms·

1) They're not the same kind of loops though 2) They're not primitives. It's very much possible to build for and while loops from elements in the Haskell stand

by fkarg 4y ago

1) They're not the same kind of loops though 2) They're not primitives. It's very much possible to build for and while loops from elements in the Haskell standard library, because you have more powerful primitives to work with. Most languages have loops as primitives.

benreesman 4y ago
By the time you’re handy with forM and whileM you’re past caring how they got imported! Regular tail-recursion takes some getting used to coming from an imperative background, it’s arguably the fork point on whether someone is going to stick it out.
- xdavidliu 4y ago
  So I came to Haskell from Scheme background, so the tail recursion was actually natural to me. In fact, about a month ago I did 2016 Advent of Code in Haskell, and toward the end, I felt like I was abusing tail recursion [1] to write iterative algorithms like breadth-first-search by essentially "repeatedly consing on to the params of tails calls", as Lispers would probably call it. The whole time I'm wondering if I'm just writing Haskell "with a heavy Scheme accent", since I see others' Haskell code make extensive use of state monads (which I still haven't attempted to understand), and I also found others' using way more of the monadic / applicative operators like "bind", etc than I have. I found the hard part of Haskell not the iteration, which from tail recursion was completely natural and straightforward, but rather worrying about the efficiency of the "repeatedly consing" part. For things like stacks, the cost is O(1), but for things like Data.Array, I wasn't sure how much shared structure there was; I mean it could totally be copying the entire array every time I "mutate" an element (not really, since it was still sort of "consing" onto the old array and not actually mutating it). [1] https://github.com/xdavidliu/advent-of-code/blob/main/2016/day24.hs https://github.com/xdavidliu/advent-of-code/blob/main/2016/d...
deleted 4y ago
[deleted]

by fkarg 4y ago

benreesman 4y ago

By the time you’re handy with forM and whileM you’re past caring how they got imported! Regular tail-recursion takes some getting used to coming from an imperative background, it’s arguably the fork point on whether someone is going to stick it out.

xdavidliu 4y ago
So I came to Haskell from Scheme background, so the tail recursion was actually natural to me. In fact, about a month ago I did 2016 Advent of Code in Haskell, and toward the end, I felt like I was abusing tail recursion [1] to write iterative algorithms like breadth-first-search by essentially "repeatedly consing on to the params of tails calls", as Lispers would probably call it. The whole time I'm wondering if I'm just writing Haskell "with a heavy Scheme accent", since I see others' Haskell code make extensive use of state monads (which I still haven't attempted to understand), and I also found others' using way more of the monadic / applicative operators like "bind", etc than I have. I found the hard part of Haskell not the iteration, which from tail recursion was completely natural and straightforward, but rather worrying about the efficiency of the "repeatedly consing" part. For things like stacks, the cost is O(1), but for things like Data.Array, I wasn't sure how much shared structure there was; I mean it could totally be copying the entire array every time I "mutate" an element (not really, since it was still sort of "consing" onto the old array and not actually mutating it). [1] https://github.com/xdavidliu/advent-of-code/blob/main/2016/day24.hs https://github.com/xdavidliu/advent-of-code/blob/main/2016/d...

deleted 4y ago

[deleted]