[Haskell-cafe] Seeking advice on a style question
conal at conal.net
Tue Dec 26 23:23:41 EST 2006
How would this example look if you named only multiply-used expressions?
I'd like to see it in a more conventional pointful style with nested
expressions. I'm still wondering whether the awkwardness results from your
writing style or is more inherent. Showing the real variable names may also
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.
This description fits expression evaluation in general. Maybe you don't
like expression-oriented programming?
On 12/26/06, Steve Schafer <steve at fenestra.com> wrote:
> 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
> >manageable? If you have real examples of State, Reader, and/or Writer
> >monads that strike you as similar to your example, please share that
> 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
> 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.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe