On 05/01/06, John Meacham <[EMAIL PROTECTED]> wrote:
> independent of anything else, giving up error messages on pattern match
> failures in do notation is not acceptable. so, if the split were to
> happen, having two methods in MonadZero, one which takes a string
> argument, would be needed.
>
>
independent of anything else, giving up error messages on pattern match
failures in do notation is not acceptable. so, if the split were to
happen, having two methods in MonadZero, one which takes a string
argument, would be needed.
John
--
John Meacham - ⑆repetae.net⑆john⑈
On 05/01/06, Taral <[EMAIL PROTECTED]> wrote:
> On 1/5/06, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> > class Applicative m => Monad m where
> > m >>= f = join (map f m)
> >
> > instance PointedFunctor m where
> > require return
> > map f x = x >>= (return . f)
>
> Um, it loo
On 1/5/06, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> class Applicative m => Monad m where
> m >>= f = join (map f m)
>
> instance PointedFunctor m where
> require return
> map f x = x >>= (return . f)
Um, it looks like map and (>>=) are recursive...
--
Taral <[EMAIL PROTEC
On 05/01/06, David Menendez <[EMAIL PROTECTED]> wrote:
> Cale Gibbard writes:
>
> > I personally feel that the inclusion of 'fail' in the Monad class is
> > an ugly solution to the problem of pattern matching, and gives the
> > incorrect impression that monads should have some builtin notion of
> >
Hi folks
Wolfgang Jeltsch wrote:
Am Mittwoch, 4. Januar 2006 21:54 schrieb Cale Gibbard:
I personally feel that the inclusion of 'fail' in the Monad class is
an ugly solution to the problem of pattern matching, and gives the
incorrect impression that monads should have some builtin notion o
search for MonadZero)
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On Behalf Of Simon Peyton-Jones
| Sent: 05 January 2006 09:06
| To: Cale Gibbard; Haskell Mailing List
| Subject: RE: [Haskell] A collection of related proposals
| regarding monads
|
|
|
| What do people think of the following proposal? Remove fail from the
| Monad class. Reinstate MonadZero as a separate class as in Haskell
| 1.4.
This was debated extensively during the Haskell 98 process. I'm not
saying that we made the right decision then, but here's a link to (a
part of) th
Cale Gibbard writes:
> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure. Indeed, it's becoming common to type the result of some
G'day all.
I wrote:
> > My feeling is that do { p <- xs; return e } should behave identically
> > (modulo the precise error message if the pattern match fails) to
> > map (\p -> e) xs. Your proposal would make it into a map/filter
> > hybrid.
Which, of course, it is now. I blame lack of caffei
Am Mittwoch, 4. Januar 2006 22:30 schrieb [EMAIL PROTECTED]:
> [...]
> Though possible "mchoose" might be more appropriate.
These leading m's are not nice in my opinion.
> Even more appropriate might be to rationalise some of these naming
> conventions.
Yes, we should remove those m's and use q
On 04/01/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> G'day Cale.
>
> Quoting Cale Gibbard <[EMAIL PROTECTED]>:
>
> > I personally feel that the inclusion of 'fail' in the Monad class is
> > an ugly solution to the problem of pattern matching, and gives the
> > incorrect impression that monad
Am Mittwoch, 4. Januar 2006 21:54 schrieb Cale Gibbard:
> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure.
I totally agree!
> [
G'day Cale.
Quoting Cale Gibbard <[EMAIL PROTECTED]>:
> I personally feel that the inclusion of 'fail' in the Monad class is
> an ugly solution to the problem of pattern matching, and gives the
> incorrect impression that monads should have some builtin notion of
> failure.
So do I.
> We ought
14 matches
Mail list logo
