No one replied to this, but I think I figured out why, when I am using the
Error monad, that every statement in a do construct runs at least part way,
whether or not its data is needed. The final output is a Left or Right
value -- and because a Left anywhere can short-circuit the compuation that
follows, there is no way for the program to decide on a final Left/Right
output without running each computation (or at least up to the point where
it's not a Left).
On Sat, Sep 1, 2012 at 12:59 PM, Dennis Raddle
I recently completed a large project and started another one. The first project was about processing music, in particular taking MusicXML and/or Sibelius files (Sibelius is a music notation program) and producing MIDI files according to the specifications I wanted.
The second project is about algorithmic music composition.
To handle errors in the first project, I used "throw" to throw exceptions.
Now I am using the Error monad... actually a combination of ErrorT and State. (In the state I hold a random generator for use in algorithms that require pseudo-randomness.)
I notice two things now. The first thing is that I can catch and rethrow errors to provide annotation about the context. It's like getting a stack trace automatically every time there is an error. I realize now this makes it easier to debug, and during my first project I spent a lot of time debugging that might have been avoidable. (I confess I never could figure out the ghci debugger, which might have helped.)
The second thing is that there seems to be less laziness. Every statement in a do statement seems to execute even if I don't use result. I think. I would have to do some more experiments, but that is what it looks like right now. That is another good thing for debugging... less laziness (and maybe guaranteed order of execution too?) means it's easier to understand what the program is attempting to do.
Does this seem correct?
Dennis