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
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/
```