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

apfelmus at quantentunnel.de apfelmus at quantentunnel.de
Wed Dec 27 11:06:24 EST 2006


Steve Schafer wrote:
> In my text/graphics formatting work, I find myself doing a lot of
> "pipeline" processing, where a data structure will undergo a number of
> step-by-step transformations from input to output. For example, I have a
> function that looks like this (the names have been changed to protect
> the innocent--and to focus on the structure):
> 
>  process :: a -> b -> c -> d -> e
>  process x1 x2 x3 x4 = 
>    let y01       = f01 x1 x2 x3;
>        y02       = f02 x1;
>        y03       = f03 y02;
>        y04       = f04 y03;
>        y05       = f05 x1 y01 y04;
>        y06       = f06 x2 y05;
>        (y07,y08) = f07 y01 y06;
>        y09       = f08 y07;
>        (y10,y11) = f09 x2 x4 y09 y08;
>        y12       = f10 y10;
>        y13       = f11 y12;
>        y14       = f12 x1 x2 x3 y01 y13;
>        y15       = f13 y14;
>        y16       = f14 y15 y11
>        in y16
> [...]
> In principle, it could be
> managed with a bunch of nested StateT monads, but my attempts to do so
> seem to get so caught up in the bookkeeping that I lose the advantages
> mentioned above.
> [...]
> So here's the question: Is there a reasonable way to express this kind
> of process (where I suppose that "reasonable" means "in keeping with
> Haskell-nature") that preserves the advantages mentioned above, but
> avoids having to explicitly pass all of the various bits of state
> around?

To me, it looks more like MonadReader than MonadState because I have the
impression that x1 and x2 are "enivronments" to fetch something from.
(Btw, MonadReader is best used as an Applicative Functor, but that's a
different story).

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.

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).


Regards,
apfelmus



More information about the Haskell-Cafe mailing list