[Haskell-cafe] Laziness and Either

[John Goerzen]

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:

http://git.complete.org/datapacker?a=blob;f=Scan.hs;h=d4e8ac8d6e883f342096a4618bb4fa9539162b79;hb=18e774ba27bd4857fd13fcbdd62083dc8c11ff56

  line 32-43 -- version that uses error

http://git.complete.org/datapacker?a=blob;f=Scan.hs;h=acd53739f5d871a3ce7ae66346050ef82c2a1254;hb=0d4e3ee6c4e5c780009ad5c09dfd79cc0df8ae90

  line 32-46 -- version that uses Either

http://git.complete.org/datapacker?a=commitdiff;h=0d4e3ee6c4e5c780009ad5c09dfd79cc0df8ae90
  
  -- diff between them

-- John