Steve, 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 help also.
You said 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? - Conal On 12/26/06, Steve Schafer <[EMAIL PROTECTED]> 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 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/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
