>> 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
I'm a brazilian student and i'm looking for some informations about Paralel
Haskell. Please, Help me...
Thanks
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
Fergus Henderson wrote:
> On 05-Nov-1998, Sven Panne <[EMAIL PROTECTED]> wrote:
> > [...] Please automatically prefix the subjects with
> > something like [haskell], [ghc-bugs], [ghc-users].
>
> BTW, this is easily done using majordomo -- you just set the
> "subject_prefix" variable in the config
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
WW
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 conc
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 "hid
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 over
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 w
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
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
>> proble
>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
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 rest
| 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 th
| 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 Mo
I agree with John P.
A memorable phrase from the opening of Backus's celebrated 1978 diatribe
(Can Programming be Liberated ...) was his dismayed reference to the
`primitive word-at-a-time style' of conventional programming languages
of the day, too much influenced by the architectural peculiarit
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 di
Colin writes
Twenty years later, must we really settle for primitive modulo-word-size
arithmetic as the default?
And many others support Integer over Int as the default default.
So do I, if it's done right. But we already decided that doing it right
is too hard for Haskell 98; it will have
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
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 pr
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 a
> 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 f
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 Int
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 ex
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 lan
> 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
> Integers are a well defined mathematical concept and the
> Integer class should reflect this. Having a bottom value seems
> wierd to me.
Indeed, I'd be quite happy to exclude it if our type systems were
powerful enough to handle it. Integers with bottom should have type
'Lif
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
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 signatures
[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<-
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
Option 1: Monad( .., mfail, mzero ), MonadPlus( mplus )
Option 2: Monad( .., mfail), MonadPlus( mzero, mplus )
Option 3: Monad( .., mfail), MonadPlus( mplus ), MonadZero( mzero )
Following Erik's note, I suggest:
Option 4: Monad( (>>=), return, mfail)
The user can define MonadZ
Lennart writes,
> - The default default.
Leave the default default alone. Since we didn't switch to
more generic versions of length et al (good move!) it doesn't
make much sense to do the default change.
I agree. (Even though I argued for the length change.) Switching Int
to Integer w
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 work
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 re
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 (an
> 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...
> mfa
37 matches
Mail list logo