[Haskell-cafe] Re: Seeking advice on a style question

Steve Schafer steve at fenestra.com
Thu Dec 28 21:41:40 EST 2006


On Wed, 27 Dec 2006 17:06:24 +0100, you wrote:

>But in general, it's futile trying to simplify things without knowing
>their meaning: names are *important*. I assume that your proper goal is
>not to structure pipeline processes in full generality, but to simplify
>the current one at hand.

No, I'm looking for full generality. ;)

I have dozens of these kinds of "quasi-pipelines," all similar in
overall appearance, but different in detail.

>Even if you wanted to simplify the general structure, I think you'd have
>to make the types of the different yk explicit. Otherwise, the problem
>is underspecified and/or one has to assume that they're all different
>(modulo some equalities implied by type correctness).

Most of them are, in fact, different types (see my reply to Conal).

--------

Here's the essence of the problem. If I have this:

 process1 x y =
   let u = foo x y;
       v = bar u;
       w = baz v
   in  w

I can easily rewrite it in point-free style:

 process1 = baz . bar . foo

But if I have this:

 process2 x y =
   let u = foo x y;
       v = bar u;
       w = baz v u
   in  w

then I can't avoid naming and using an intermediate variable. And that
annoys me. The u in process2 is of no more value to me (pardon the
pun) as the one in process1, but I am forced to use it simply because
the data flow is no longer strictly linear.

The reason I brought up monads as a possible means of managing this
problem is that the State, Reader and Writer monads already handle
certain specific "shapes" of nonlinear data flow, which suggested to
me that maybe there was a monadic approach to managing nonlinear data
flow in a more general way. Of course, if there is a non-monadic,
purely functional way to do it, that would be even better, but I've
never seen such a thing (short of doing lots of tupling and
un-tupling).

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/


More information about the Haskell-Cafe mailing list