
This rewrite changes the order of execution. The old version did all of the
putDirs and then all of the renameFile calls. The new one interleaves
putDirs & renameFile calls. In general, ">>" is not commutative, though in
this case you may be as happy with either order. - Conal
On 12/12/06, Bryan Burgers
On 12/12/06, Louis J Scoras
wrote: I have some IO actions that I want to map over a list of pairs -- these are just directory names and their down-cased versions. It wasn't difficult to actually get the right behavior by just doing mapM twice.
-- putDirs just outputs something like "mv fst snd" mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs
This bothered me though, because I suspected that this could be done in one pass. Naively I proceeded to this.
mapM_ (putDirs >> (uncurry renameFile)) pairs
Which didn't work. I thought about it a little more before realizing that putDirs wouldn't get any parameters this way: I needed some way to distribute the pair over both operations. Here's the higher-order function I needed:
foo h f g i = h (f i) (g i)
which could then be curried and we get:
mapM_ (foo (>>) putDirs $ uncurry renameFile) pairs
Works great. So my question: is there a established name for foo? What about foo partially applied to (>>)? This was a fun exercise, but I'd like to use the standard implementations if they exist.
Before we get too far down the obfuscation road, I'd like to offer what I think is more readable than a liftM2 solution:
mapM_ (\p -> putDirs p >> uncurry renameFile p) pairs
I haven't tested it, but I hope that does the same thing. To me, this explicitely shows what each is doing, moreso than with a point-free 'foo' combinator.
The way my mind worked to get to this solution:
mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs
==>
mapM_ (\p -> putDirs p) pairs mapM_ (\p -> uncurry renameFile p) pairs
==>
mapM_ (\p -> putDirs p >> uncurry renameFile p) pairs
Is that a reasonable solution?
Bryan Burgers _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe