Dean Herington wrote:
> > Why is that expression not type-correct?
>
> [Answering my own question...]
>
> Duh. Because the type doesn't partake of Eq.
Right. Of course, it's a different kind of error than for example
[Orange] == Orange --- where no Eq Color instance decl would help,
and I w
Dean Herington wrote:
> On Tue, 29 Oct 2002, Christian Sievers wrote:
>
> > I guess "equivalent" just means equality without suggesting that the type is
> > an instance of Eq. There are other places where the report uses == in
> > situations where you can't really apply it, for example, in D.2 it
On Tue, 29 Oct 2002, Christian Sievers wrote:
> I guess "equivalent" just means equality without suggesting that the type is
> an instance of Eq. There are other places where the report uses == in
> situations where you can't really apply it, for example, in D.2 it says
> "we would have
>
On Tue, 29 Oct 2002, Simon Peyton-Jones wrote:
> Some last-ditch H98 stuff. I have the proofs now and have to send them
> back this week. Changes will become impossible (or at least much
> harder) after that. Ah well, I'm sure more errors will come to light.
>
> Simon
>
>
> | > | (3) Section
Simon Peyton-Jones wrote:
> I can only make minimal changes now. I suspect the smallest change is
> to require that
> (x,"") `elem` readsPrec d (showsPrec d x "")
>
> This weakens the existing equation by not requiring (x,"") to be the
> first parse returned.
>
> Dean writes:
> | Perha
Some last-ditch H98 stuff. I have the proofs now and have to send them
back this week. Changes will become impossible (or at least much
harder) after that. Ah well, I'm sure more errors will come to light.
Simon
| > | (3) Section D.4 gives the expected rule:
| > |
| > | head (readsPrec d
Simon Peyton-Jones wrote:
> | (1) In the first section, in:
> |
> | instance (cx, cx') => Ci (T u1 ... uk) where { d }
> |
> | the use of "(cs, cs')" is a bit loose (that is, suggestive rather than
> | precise syntax). One can't (according to the report, though GHC seems
> to
> | allow it) ha
| (1) In the first section, in:
|
| instance (cx, cx') => Ci (T u1 ... uk) where { d }
|
| the use of "(cs, cs')" is a bit loose (that is, suggestive rather than
| precise syntax). One can't (according to the report, though GHC seems
to
| allow it) have nested parentheses in a context, which
Simon Peyton-Jones wrote:
> | In GHC 5.04.1, derived instances of Show mishandle precedence:
> |
> | Prelude> putStrLn (showsPrec 10 (Just 0) "")
> | Just 0
> |
> | The result should be: (Just 0)
>
> I think it's a bug in the Report, not in GHC, actually. The Report says
> (Section D.4)
>
> "
| In GHC 5.04.1, derived instances of Show mishandle precedence:
|
| Prelude> putStrLn (showsPrec 10 (Just 0) "")
| Just 0
|
| The result should be: (Just 0)
I think it's a bug in the Report, not in GHC, actually. The Report says
(Section D.4)
"The function 'showsPrec d x r' accepts a pre
10 matches
Mail list logo
