4 ms·
Yes and no. In practice, you're going to fold into a different domain, which causes the types of the reduce function arguments to be different. Moreover, you ar
by pacala 14y ago
Yes and no. In practice, you're going to fold into a different domain, which causes the types of the reduce function arguments to be different. Moreover, you are not going to have your reduce function conveniently in a library. You are going to have to write a loop body. At which point, choosing a block over a for loop becomes purely religious.
- krichman 14y agoDifferent domain is fine. [1,2,3].reduce([], &:unshift) #=> [3,2,1] I don't see a problem with writing a for loop, but I think it's not as composable and it can be a little harder to read. So I don't think it's purely religious but it's close to that.
- pacala 14y agoRandomly searching for foldr on code.google.com inserts :: [(VarId,VarId)] -> Env -> Env inserts vvs env = foldr (\(a,b) acc -> M.insert a b acc) env vvs or inserts(vvs, env) { for ((a, b) : vvs) { env = M.insert(a, b, env) } return env } Pick your poison, but I'll stick with fors. Go blues!
- krichman 14y agoIf you want inscrutable Haskell you should go with the <$> operators :) I'd personally still rather have a vvs.reduce(env){|env, (a,b)| M.insert(a, b, env)} but the for loop is perfectly readable also because it fits on a single line. I think for longer bodied reduces I might prefer a for loop actually.