Lennart wrote:
Sorry, I'm not happy with this proposal. Monads are a well
defined mathematical concept and I think the Monad class should
reflect this. Having a mzero (and mfail) method seems weird to
me. I would suggest a MonadZero class having these methods,
and that do notation on works
To my reply
I join this suggestion.
..
ad hoc polymorphism is still very desirable.
As they are the overlapping instances with ad hoc resolution - more
generic than allowed by recent Haskell compilers.
Michael Hobbs [EMAIL PROTECTED] writes
When considering changes to a language, I
On 04-Nov-1998, Michael Hobbs [EMAIL PROTECTED] wrote:
"S.D.Mechveliani" wrote:
When considering changes to a language, I think one needs to carefully
measure the difference between convenience and necessity/correctness. I
think everyone will agree that ad hoc polymorphism (aka
On 04-Nov-1998, Claus Reinke [EMAIL PROTECTED] wrote:
seems like another reason to advocate ad hoc polymorphism
(allow a name to denote several things, as long as they have
different types).
How much ``ad hoc'' would you like? Hugs 1.3c [March 1998 p1]
accepts the following without
On 04-Nov-1998, Erik Meijer [EMAIL PROTECTED] wrote:
Let me try to sketch a design methodology for introducing type classes
[...]
It is good style to define non-overloaded versions of class methods outside
of the class instead of inlining them in the instance declaration. For
example the
On 05-Nov-1998, Lennart Augustsson [EMAIL PROTECTED] wrote:
Simon wrote:
- The do-expression and MonadZero debate. You'll have seen a
lot about this, and I'll circulate a separate proposal.
Sorry, I'm not happy with this proposal. Monads are a well
defined mathematical concept and I
Perhaps a "better" solution than ad hoc polymorphism would be to provide
a more convenient namespace syntax. Am I mistaken in thinking that
overloading, for overloading's sake, isn't what is wanted; what is
wanted is to be able to easily differentiate between two functions that
happen to be
There is no need to have both `mzero' and `mfail' in every monad.
Just have `mfail'. Leave `zero' and `plus' to MonadPlus. This should
make Eric partially happy. It also means one can simply write
instance Monad [] where
...return, =, as before...
mfail s = []
Option 1: Monad( .., mfail, mzero ), MonadPlus( mplus )
Option 2: Monad( .., mfail), MonadPlus( mzero, mplus )
Option 3: Monad( .., mfail), MonadPlus( mplus ), MonadZero( mzero )
I prefer 3 (with 2 as a close second) since it is most like status quo.
-- Lennart
On 04-Nov-1998, Jan Skibinski [EMAIL PROTECTED] wrote:
Some languages have a renaming mechanism, which allows
to retain old functions under the names different than
the original ones. This is not the same as "hiding".
No, but you can simulate it very easily using "hiding":
Simon Peyton-Jones [EMAIL PROTECTED] writes
- The simple-context restriction.
...
My default position is not to change. Question: who, apart from
Ralf, has actually tripped over the lack of contexts of the
form (C (a t1 .. tn)) in Haskell 1.4? Is their lack a real
problem in practice?
Simon wrote:
- The do-expression and MonadZero debate. You'll have seen a
lot about this, and I'll circulate a separate proposal.
Sorry, I'm not happy with this proposal. Monads are a well
defined mathematical concept and I think the Monad class should
reflect this. Having a mzero (and
Haskell 98 libraries
* Make each module export all the relevant types and functions that the
Prelude defines, so that a programmer who does not import the Prelude
can get access to all the (say) list types and functions by saying
import List. This involves extra exports from
On 5 Nov, Simon Peyton-Jones wrote:
I don't like grabbing too many very generic names like zero, plus, fail
from the user (this is all in the Prelude, remember). I don't want
to grab 'raise' because we're going to want it for exceptions in Haskell
2. I havn't been able to think of
Simon Peyton-Jones wrote about Phil Wadler's idea:
| Good idea! So your suggestion is:
|
| class Monad m where
| ...return, =, as before...
|
| mfail :: String - m a
|
| class MonadPlus m where
| mplus :: m a - m a - m a
| mzero :: m a
I
On 05-Nov-1998, Lennart Augustsson [EMAIL PROTECTED] wrote:
If Integers can have "error", why shouldn't Monads have "mfail"?
I'm objecting less to mfail then mzero.
OK, in that case I agree with you.
--
Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit
WWW:
Here's an even better idea: replace mfail with fail.
It is, after all, the fail of the IO monad!
Option 4'': Monad ((=), return, fail)
-- P
The names `mzero' and `mfail' are horrible. I like Ralph's suggestion
to change `fail' to `raise' in the IO monad, and use `fail' for
`mfail'. If that doesn't work, try something else, but please
pick names that have a simple meaning in English (as with `return')
not monsters like `mzero'
| Here's an even better idea: replace mfail with fail.
| It is, after all, the fail of the IO monad!
|
| Option 4'': Monad ((=), return, fail)
Unfortunately not, fail of IO fame has type
IOError - IO a
and not
String - m a
as Monad's new member.
Here's my suggestion:
o Monad
I don't understand the opposition to changing the default default to
Integer. This certainly won't break anything in any sort of serious
way (only for exported values with no type signature attached),
probably has only a minimal effect on performance - quite easily
corrected using type
Simon Peyton-Jones [EMAIL PROTECTED] writes
- The simple-context restriction.
...
My default position is not to change. Question: who, apart from
Ralf, has actually tripped over the lack of contexts of the
form (C (a t1 .. tn)) in Haskell 1.4? Is their lack a real
problem in practice?
[EMAIL PROTECTED]
Welcome to the haskell mailing list!
If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:
unsubscribe haskell -your email address-
Ralph writes,
Unfortunately not, fail of IO fame has type
IOError - IO a
and not
String - m a
as Monad's new member.
Here's my suggestion:
o Monad ((=), return, fail)
o throw (thanks Frank) instead of fail for the IO operation
o raise for Haskell-2's
John Peterson writes
Int is really not a nice
datatype and we shouldn't be allowing it to crop up unexpectedly.
Yes, but if we believed that, we should use Integer, not Int, for
length.
You are right, beginners may stub their toe on factorial. On the other
hand, with the default set to
| John Peterson writes
|
| Int is really not a nice
| datatype and we shouldn't be allowing it to crop up unexpectedly.
|
| Yes, but if we believed that, we should use Integer, not Int, for
| length.
|
| You are right, beginners may stub their toe on factorial. On the other
| hand, with
Philip Wadler wrote:
You are right, beginners may stub their toe on factorial. On the other
hand, with the default set to Integer, beginners may stub their toe
on bad performance. Anyone familiar with, say, C, will be unsurprised
by the need to switch Int to Integer to get factorial to
Hi, it seems to be much too late after all the discussion but among
the alternatives was
3. Make tuples special, so that g would be in Monad, but
if we had a user-defined single-constructor type instead
then it would be in MonadZero
about which was said
In using Derive to generate Haskell code, I have run into two Gotcha's
that I am not sure need to be there:
1. "multiply defined"
I get this error message if I attempt to do
sqlType "Int" = "Integer"
h=2 -- removing this line makes this code work
sqlType "String" = "VarChar(255)"
This
I'm a brazilian student and i'm looking for some informations about Paralel
Haskell. Please, Help me...
Thanks
Haskellers,
Can folk please watch who they're replying to when they answer messages on
the list.
Due to various quirks in the mailing list system at Glasgow, the address
[EMAIL PROTECTED] appears in the message headers and tends to
make its way into the CC: list of an automatic reply. This
The Deputy wrote:
[...] Due to various quirks in the mailing list system at Glasgow, [...]
Just a suggestion: Simply use Majordomo for the mailing list.
http://www.greatcircle.com/majordomo/
It has none of these problems, is extremely easy to install, and is very
well documented. We run
31 matches
Mail list logo
