Hi fellow debaters,
>I hope you've had fun with all the MonadZero mail.
I surely did.
>My conclusion: we should combine Monad and MonadZero.
>Sorry Erik, but you are now the lone voice in the wilderness.
Don't worry, I am used to that :-)
>Here's a concrete proposal:
>
>That's it! Comments?
On Wed, 4 Nov 1998, Michael Hobbs 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 overloading) is
> very _convenient_ but I don'
- The simple-context restriction. My difficulty here is that there
is just no good place to stop. The 'type variable in head position'
option is attractive, but it's unimplemented, untested, and it's
neither the status quo nor a final destination. On the other hand,
we *believ
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 = [
"S.D.Mechveliani" wrote:
>
> To
>
> >> I am writing code that would like to use the word "product" as a field
> >> selector for a Product (object representing something for sale).
> >> Unfortunately, it can't easily use "product" because the prelude claims
> >> the word for multiplication.
>
>
On Wed, 4 Nov 1998 03:36:05 +1100
Fergus Henderson <[EMAIL PROTECTED]> wrote:
> On 03-Nov-1998, Michael Hanus <[EMAIL PROTECTED]> wrote:
> > This sounds interesting but how did you implement it?
> > As far as I know, the problem of type inference with polymorphic
> > recursion is undecidable due t
I'm with the Option 2 Zap MonadZero Today lobby.
I dislike ~ patterns for all sorts of reasons (won't drag up all *that*
again now!) but that the introduction or elimination of a ~ can alter
the *type* of an expression is particularly horrible.
The attempt to introduce notions of guaranteed eval
> The nice thing about Monads+the do-notation is that it gives you a natural
> hook to catch pattern match failures! We must nurture every chance we have
> to improve staticness of typing. I don't agree with your argument that
> because pattern match failure in function definitions is not catched
| I don't agree with your argument that
| because pattern match failure in function definitions is not catched by the
| type-checker justifies dropping that extra safety for pattern matching in
| the do-notation.
You've missed my point, the nub of which was that we should get
our compilers to che
> I am writing code that would like to use the word "product" as a field
> selector for a Product (object representing something for sale).
> Unfortunately, it can't easily use "product" because the prelude claims
> the word for multiplication.
seems like another reason to advocate ad hoc polym
John,
>Of course we would all like Haskell to catch as many errors as possible,
and statically. But a chain is only as strong as its weakest link. When
there are already weak links in a chain, it makes no sense to build others
of some hi-tech super strong material. The most efficient design occur
On 03-Nov-1998, Mark P Jones <[EMAIL PROTECTED]> wrote:
> ghc doesn't need to use an iteration limit because it subjects the input
> source program to stricter limits to guarantee decidability.
The release notes for ghc 4.00 mention a new `-fallow-undecidable-instances'
option. I presume that it
On 03-Nov-1998, Michael Hanus <[EMAIL PROTECTED]> wrote:
> Fergus Henderson wrote:
> > >Is there any Haskell implementation that supports polymorphic recursion
> > > without the need of annotating the types for defined function by the
> > > programmer?
> >
> > Not as far as I know.
> >
> > H
> I would like to lobby to move sum and product to the list library.
> Or, to rename them listSum, listProduct.
> (so that a user can use the names sum and product for
> whatever is their
> primary data structure e.g. tree)
As someone said, I think 'hiding' is what you want.
Your suggestion is q
> I don't know whether ghc uses an iteration limit mechanism --
> my guess is that it probably uses the same technique as Hugs.
No, it's an iteration limit. (When you say -fallow-undecideable-instances).
Simon
15 matches
Mail list logo
