Duncan Coutts wrote:
Another approach that some people have advocated as a general purpose
solution is to use:
data Exceptional e a = Exceptional {
exception :: Maybe e
result:: a
}
However it's pretty clear from the structure of this type that it cannot
cope with lazy error
wren ng thornton wrote:
One of the nice things about not having a Nil is that it lets you easily
be polymorphic over things ending in () ---a normal list---, (Maybe a)
---a fallible list---, (Either a b) ---your progress type---, etc.
Whereas the version that has both Nil and End forces us
On Thu, 2009-12-03 at 19:49 -0500, wren ng thornton wrote:
Duncan Coutts wrote:
I've got an open mind on the suggestion to amalgamate the two ways the
list could end. I'm not especially in favour of generalising for the
sake of generalising, especially if it looses the connection to the
wren ng thornton wrote:
concat1 :: T a b - (b - T a b) - T a b
This could just as easily be
concat :: T a b - (b - T a c) - T a c
right? It's a little weird to call this concatenation, but I bet it
could come in handy.
--
Jason McCarty jmcca...@sent.com
On Fri, Dec 4, 2009 at 1:14 PM, Jason McCarty jmcca...@sent.com wrote:
wren ng thornton wrote:
concat1 :: T a b - (b - T a b) - T a b
This could just as easily be
concat :: T a b - (b - T a c) - T a c
right? It's a little weird to call this concatenation, but I bet it
could come in
Jason McCarty wrote:
wren ng thornton wrote:
concat1 :: T a b - (b - T a b) - T a b
This could just as easily be
concat :: T a b - (b - T a c) - T a c
right? It's a little weird to call this concatenation, but I bet it
could come in handy.
Er right, that's what I meant. (Again the
Duncan Coutts duncan.cou...@googlemail.com writes:
[1] http://hackage.haskell.org/package/failable-list
Nice.
I agree this is needed (or rather, would be nice to standardise).
Although I don't care for the cutesy naming suggested in the 'Train'
datatype, failable-list could be made more
data TerminatedList a e = Then a (TerminatedList a e)
| Finally e
Nice.
(So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` success!.
Errm, you mean: 4 `Then` 5 `Then` 1 `Then` Finally success!
Regards,
Malcolm
On Thu, 2009-12-03 at 12:34 +0100, Ketil Malde wrote:
Duncan Coutts duncan.cou...@googlemail.com writes:
[1] http://hackage.haskell.org/package/failable-list
Nice.
I agree this is needed (or rather, would be nice to standardise).
Although I don't care for the cutesy naming
Malcolm Wallace malcolm.wall...@cs.york.ac.uk writes:
Errm, you mean: 4 `Then` 5 `Then` 1 `Then` Finally success!
Yes, sorry, and thanks. I guess I should learn to check with ghci
before posting... How about this for a nicer syntax?
infixr 8 :+
infixr 8 +:
data TList a e = a :+
Duncan Coutts wrote:
I've got an open mind on the suggestion to amalgamate the two ways the
list could end. I'm not especially in favour of generalising for the
sake of generalising, especially if it looses the connection to the
notion of annotating your ordinary data structure with extra
On Mon, 2009-11-30 at 20:10 -0800, John Millikin wrote:
On Mon, Nov 30, 2009 at 03:02, Duncan Coutts
duncan.cou...@googlemail.com wrote:
data ListThenError e a = Cons a (ListThenError e a)
| Error e
Of course this has the disadvantage that then your consumer must
On Mon, 2009-11-30 at 06:08 +, Malcolm Wallace wrote:
However, if you really want to terminate the stream at
the first error, and to reflect this in the type, then I guess you can
define your own list type:
data ListThenError e a = Cons a (ListThenError e a)
On Mon, Nov 30, 2009 at 6:22 AM, John Millikin jmilli...@gmail.com wrote:
...I've considered two possible error handling modes...
Regarding parsing, there's a third option: iteratees[1]. See [2] for a
motivation and description of iteratees.
regards,
Bas
[1]
On Mon, Nov 30, 2009 at 03:02, Duncan Coutts
duncan.cou...@googlemail.com wrote:
On Mon, 2009-11-30 at 06:08 +, Malcolm Wallace wrote:
However, if you really want to terminate the stream at
the first error, and to reflect this in the type, then I guess you can
define your own list type:
I'm working on a library which needs to operate on large data sets, so
I'd like to use lazy values. The library consists of pure functions
from Text to [Event] and back. Normally, I use Maybe or Either for
error handling in pure code, but using these precludes lazy
evaluation. Using exceptions
I'm working on a library which needs to operate on large data sets, so
I'd like to use lazy values. ...
import qualified Data.Text as T
parse :: TL.Text - [Either ParseError Event]
I would say that this is the
On Sun, Nov 29, 2009 at 11:08 PM, Malcolm Wallace
malcolm.wall...@cs.york.ac.uk wrote:
Are you sure that there can be no error recovery, to continue with events
after a mal-formed event has been discarded? In many cases, it is possible.
However, if you really want to terminate the stream at
18 matches
Mail list logo
