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
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
On Fri, Dec 4, 2009 at 1:14 PM, 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 h
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
__
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 t
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 into
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 error
Malcolm Wallace 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 :+ (TList a e)
On Thu, 2009-12-03 at 12:34 +0100, Ketil Malde wrote:
> Duncan Coutts 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'
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
___
Duncan Coutts 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 general. Why is there a
spe
On Mon, 2009-11-30 at 20:10 -0800, John Millikin wrote:
> On Mon, Nov 30, 2009 at 03:02, Duncan Coutts
> wrote:
> >> data ListThenError e a = Cons a (ListThenError e a)
> >> | Error e
> >>
> >> Of course this has the disadvantage that then your consumer must
> >> change to
On Mon, Nov 30, 2009 at 03:02, Duncan Coutts
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:
>>
>> data ListThenError
On Mon, Nov 30, 2009 at 6:22 AM, John Millikin 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] http://hackage.haskell.org/package/iteratee
[2] http:
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 Sun, Nov 29, 2009 at 11:08 PM, Malcolm Wallace
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 the first error, and
> to re
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 mos
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 requ
18 matches
Mail list logo
