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 <[EMAIL PROTECTED]> wrote:

On 12/12/06, Louis J Scoras <[EMAIL PROTECTED]> 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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to