| As you probably know, GHC and Hugs now support an exception mechanism
| which lets you recover from calls to 'error' -- but of course that's
| not in H98.
Sorry Simon, but it's not supported in any currently
released version of Hugs either.
All the best,
Mark
I have three small questions.
1.
Haskell-98 description
- is it ready to print as the final, accepted and approved document?
2.
Question by Jose Emilio Labra Gayo <[EMAIL PROTECTED]>:
> Is it better to type the derived methods inside the class
> definition or out? Are there any efficiency pe
(I meant to send this to the Haskell list this morning, but hit reply and
didn't get what I expected!)
-Original Message-
From: michael abbott [mailto:[EMAIL PROTECTED]]
Sent: 28 January 1999 10:13
To: 'Jose Emilio Labra Gayo'
Subject: RE: A simple question on Haskell style
The essentia
On 27-Jan-1999, Michael Hobbs <[EMAIL PROTECTED]> wrote:
> Ross Paterson wrote:
> >
> > John Hughes has defined a new abstract view of computation, in his
> > (currently draft) paper "Generalising Monads to Arrows", at
> >
> > http://www.cs.chalmers.se/~rjmh/Papers/arrows.ps
>
> Has any
===
S E C O N D C A L L F O R P A P E R S
===
SPECIAL SESSION
"H
Except that he does say in the conclusion of the paper: "This paper
proposes the replacement of monads as a structuring tool for combinator
libraries, by arrows."
I don't think he made that argument though; I think the argument he made was
that arrows could be an alternative structuring tool f
Michael Hobbs writes:
Yes, I can see how the arrow paradigm would work very well for
things such as parsing LL(1) grammars, but I could not see how such
a scheme could become a _replacement_ for monads in general purpose
programming. Perhaps I was expecting the wrong thing from the
Suppose I define a new type class MyClass with some methods
class MyClass a where
-- Basic methods
m :: Some type including a
...
-- Derived Methods
dm :: Some type including a
dm = Definition of dm that depends on m
...
However, I could r
David Barton wrote:
> Hmmm. *If* you believe that monads are a useful construct, and
> understand them to an extent, then it is not clear to me why you would
> have that much difficulty here. (Sorry, that came out as very
> negative --- I just mean that the concepts are so similar that an
> unde
Ralph,
> you said that `fail' intentionally calls `error' in the IO monad
> because it corresponds to pattern matching failure. I would buy this
> argument if `fail' were used only internally. But it is exposed to the
> user: she or he is free to call `fail'. Now, in the list
> monad `fail s'
>
> 1.
> Haskell-98 description
> - is it ready to print as the final, accepted and approved document?
Design frozen: but I'm working right now on the actual final document.
> class Num' a where add,sub :: a -> a -> a
> neg :: a -> a
> sub x y = a
I'm working my way through both papers now (arrows, and deterministic
error-correcting parsers). They're very interesting.
I wanted to point out that I see a similarity to work being done in the C++
community with "template metaprograms" and "active libraries", where some
library developers (t
I propose to remove Show (IO a) as well as Show (a->b),
for the same reason
Simon
Folks,
I've been doing the final clean-up of typographical errors in the
Haskell report. This messages summarises anything non-trivial
that I've done. I'll put out the final version shortly.
There are two points that came up that seem substantial:
1. I think we decided a while ago to remove
Michael Hobbs writes:
Has anyone else read this paper? I'm interested in hearing
comments, if only to point out some things that I may have
missed. I'll admit, I haven't read the entire paper. I gave up
after the 16th page, because it was so conceptually unwieldy. It's
not that I h
> Is it better to type the derived methods inside the class
> definition or out? Are there any efficiency penalties
> in any of the styles?
>
> In Haskell98 Prelude there is a mixture of both styles, for example,
> (>>) is defined inside the Monad class, but (=<<) is left out.
Good question.
16 matches
Mail list logo
