[Haskell-cafe] Laziness and Either

John Goerzen 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

-- John

More information about the Haskell-Cafe mailing list