| I agree that this is an error that you would like the system to catch.
| I disagree strongly with the suggestion that this is an error that you
| should expect the *type system* to catch.
|
| Suppose that the original version of your nuclear reactor driver also
| contained a definition:
|
|
| I think Hugs 1.3c and recent versions of ghc both support undecideable
| features in their type systems -- but related to typeclasses and
| instance declarations rather than to polymorphic recursion.
|
| From email with Mark Jones, I gather that Hugs does not use an
| iteration limit mechanism,
| I want to make a different plea: keep the language design consistent!
| Yes, the difference between f, g, h is a wart, but let's have one wart
| repeated, rather than two different warts.
I am not convinced. This argument could be reverted to support
alternative 2. Haskell uses patterns in many
On 02-Nov-1998, Tomasz ?ukaszewicz <[EMAIL PROTECTED]> 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.
However, the current Mercury implementation suppor
| > b) if you add an extra constructor to a single-constructor type
| >then pattern matches on the original constructor suddenly become
| >failable
|
| That is great. I'd rather have this as a static error that getting an
| unexpected pattern match failure in my nuclear reactor device driver:
Erik Meijer wrote:
| > b) if you add an extra constructor to a single-constructor type
| >then pattern matches on the original constructor suddenly become
| >failable
|
| That is great. I'd rather have this as a static error that getting an
| unexpected pattern match failure in my
Thanks for the further explanation.
On reflection there probably shouldn't be a default declaration for mzero.
Any compiler for Haskell must do *something* if a method is
called for which there is neither an explicit declaration in
the instance, nor a default method. ... Leaving out th
| > 1.Fix up the current version.
| > use MonadZero for do expressions with *irrefutable* patterns
| > (instead of *unfailable* patterns as now)
| > 2.Nuke MonadZero altogether.
| > add mfail :: m a to Monad instead
I opt for 2. It's certainly true that the second choice breaks exist
Ralf says,
Why should we introduce
concepts (irrefutable, unfailable) only for monad expressions?
`Unfailable' was introduced explicitly for monad expressions, and I
(and many others) agree it should not be introduced just for `do'.
`Irrefutable' is already part of the language, see the Hask
Hi,
>Erik Meijer also spoke up vigorously in defence of MonadZero.
The reason for this is that I want the type-checker to catch as many errors
as possible.
>But the Haskell 1.4 story is unattractive becuase
> a) we have to introduce the (new) concept of unfailable
Compared to many other concep
Simon says,
> Sorry, I don't understand option 2, can you please explain?
* Eliminate MonadZero
* Add 'mfail :: m a' to Monad, with a suitable default decl
* Every do expression has a type in Monad
I must be dense this morning, as I'm still in the dark. What is the
i
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.
I would like to lobby to move sum and product to the list
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.
>
> However, the current Mercury implementation supports this.
This sounds in
| > 1.Fix up the current version.
| > use MonadZero for do expressions with *irrefutable* patterns
| > (instead of *unfailable* patterns as now)
| > 2.Nuke MonadZero altogether.
| > add mfail :: m a to Monad instead
There is another variation on 2 that you don't seem to be considerin
Simon says,
Here are the two proposals I suggested in
http://research.microsoft.com/Users/simonpj
> 1.Fix up the current version.
> use MonadZero for do expressions with *irrefutable* patterns
> (instead of *unfailable* patterns as now)
> 2.Nuke MonadZero altogether
> * Eliminate MonadZero
> * Add 'mfail :: m a' to Monad, with a suitable default decl
> * Every do expression has a type in Monad
>
> I must be dense this morning, as I'm still in the dark. What is the
> intended meaning of `mfail'? If `mfail' is `mzero', why change the
> nam
> > 2.Nuke MonadZero altogether.
> > add mfail :: m a to Monad instead
>
> Sorry, I don't understand option 2, can you please explain?
* Eliminate MonadZero
* Add 'mfail :: m a' to Monad, with a suitable default decl
* Every do expression has a type in Monad
> Ye
Folks
Just to keep you informed, here's a quick summary of what I'm up to.
I plan to implement the changes proposed on
http://research.microsoft.com/Users/simonpj/Haskell/haskell98.html
with the following exceptions
* I'm still undecided about MonadZero (see last message)
* Ditto the
Folks,
I'm working on the Haskell 98 report this week, but I'm *still*
not sure what to do about the dreaded MonadZero issue, so this message
has one last go at presenting the issues.
Here are the two proposals I suggested in
http://research.microsoft.com/Users/simonpj
> 1.Fix up the
19 matches
Mail list logo
