[Haskell-cafe] Laziness and Either
jgoerzen at complete.org
Mon Apr 21 14:18:25 EDT 2008
Back when I was working on the logic for the bin-packing solver that I added
to MissingH (for use with datapacker), I had a design decision to make: do I
raise runtime errors with the input using error, or do I use an Either type
to return errors?
Initially, for simplicity, I just used error. But when I did a simple
refactoring to use Either, it occurred to me that this switch likely had a
negative impact on laziness.
In this particular algorithm, we cannot tell for sure that we have no errors
until we have consumed all items of the input list. This is unlike, say, a
safe version of "head" where you can tell whether you have an error just by
whether you have an empty list or not.
In the case of using "error", we can happily process the data assuming
everything will be fine, and raise an error if and when it is encountered.
By using Either, however, any pattern match on the Left/Right result is
going to force the entire input to be evaluated so that we can know whether
or not it had any error.
Is this analysis sensible? If so, are there better solutions?
BTW, here are links to the code I'm talking about:
line 32-43 -- version that uses error
line 32-46 -- version that uses Either
-- diff between them
More information about the Haskell-Cafe