On Mon, Apr 21, 2008 at 2:18 PM, John Goerzen [EMAIL PROTECTED] wrote:
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
On Mon, 2008-04-21 at 21:26 +0100, Magnus Therning wrote:
John Goerzen wrote:
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
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.
On Apr 21, 2008, at 11:18 AM, John Goerzen wrote:
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
On Mon, 21 Apr 2008, Donn Cave wrote:
On Apr 21, 2008, at 11:18 AM, John Goerzen wrote:
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
John Goerzen wrote:
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
But when I did a simple
refactoring to use Either, it occurred to me that this switch likely
had a
negative impact on laziness.
Yes, probably.
Is this analysis sensible? If so, are there better solutions?
I notice that your Maybe-based code is written in a monadic style. If
you also
On Mon April 21 2008 3:26:04 pm Magnus Therning wrote:
In order to allow lazy decoding I ended up exporting decode' as well:
decode' :: String - [Maybe Word8]
I take it that in a situation like this, you'd have either:
[] -- success with empty result
a list full of Just x
-- success
