[Haskell-cafe] Seeking advice on a style question
Steve Schafer
steve at fenestra.com
Tue Dec 26 21:56:11 EST 2006
On Tue, 26 Dec 2006 10:28:22 -0800, you wrote:
>So I'm still doubtful that a monadic approach is going to simplify your
>code. Would you give a real example of some code you'd like to make more
>manageable? If you have real examples of State, Reader, and/or Writer
>monads that strike you as similar to your example, please share that also.
I didn't mean to imply that a monadic approach would simplify the
code, only that it was _conceivable_ to me that such a thing might be
true. The code I showed _is_ a real example; I just changed the names
of everything to focus on the structure. And the reason for focusing
on the structure is that I'm looking for a _general_ principle to
apply to make the code more manageable; the process that I showed is
just one of many similarly-structured processes that are involved in
the actual application.
I think the essence of my question might have gotten lost, so I'll try
a slightly different approach: I have a process that consists of a
series of steps. If each step consumed _only_ the results of the
previous step, I could of course describe the process like this:
process = f14 . f13 . f12 ....
But that isn't quite the case. Each step consumes not only the results
of the previous step, but also some combination of the results of
prior steps and/or the original inputs. One way to look at this is a
directed graph, a sort of "branching pipeline"; see
http://www.dendroica.com/Scratch/process.png.
Now, the advantages of this kind of visual representation of the
process are that it makes it perfectly clear what each step consumes
and how the "flow" of the process occurs. Another big advantage (to
me, anyway) is that the graphical representation is entirely
point-free; the picture isn't cluttered with intermediate values whose
only purpose is to hold onto things I need later, but not right now.
So here's the (restated) question: Is there some way to represent the
process in good ol' text form that preserves the elegance and
conciseness of the graphical representation?
Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
More information about the Haskell-Cafe
mailing list