| > These invariants are basically impossible to enforce by the compiler,
| > but nonetheless certain classes have laws which are expected to hold,
| > and I would not be surprised if (for example) GHC optimization RULES
| > depended on them.
|
| I, in fact, would be surprised if there were such de
On 10/18/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> I don't believe GHC relies on any class laws. It'd be pretty dangerous to do
> so, I think.
Incidentally, I consider it a slight infelicity that the H98 spec
doesn't seem to mention the implied laws of classes like Eq and Ord,
not even
Just today I was looking at the implementation of Arrows and noticed this:
{-# RULES
"compose/arr" forall f g .
arr f >>> arr g = arr (f >>> g)
... other rules ...
#-}
But consider this "Arrow":
newtype (a :>> b) = LA2 { runLA2 :: [a] -> [b] }
instance Arrow (:>>) where
[EMAIL PROTECTED] On Behalf Of Ryan
| Ingram
| Sent: 19 October 2007 07:01
| To: Simon Peyton-Jones
| Cc: haskell-cafe@haskell.org
| Subject: Re: [Haskell-cafe] Class invariants/laws
|
| Just today I was looking at the implementation of Arrows and noticed this:
|
| {-# RULES
| "compose/arr"
Ryan Ingram wrote:
On 10/18/07, Janis Voigtlaender <[EMAIL PROTECTED]> wrote:
Yes, but that's a problem of the Arrow library writer, not of GHC. The
compiler will never check a RULE.
I'm going to disagree a bit here; it's not the problem of the Arrow
library writer at all, it's the problem o
Ryan Ingram wrote:
Just today I was looking at the implementation of Arrows and noticed this:
{-# RULES
"compose/arr" forall f g .
arr f >>> arr g = arr (f >>> g)
... other rules ...
#-}
But consider this "Arrow":
newtype (a :>> b) = LA2 { runLA2 :: [a] -> [b] }
instance Arrow
G'day all.
Quoting Janis Voigtlaender <[EMAIL PROTECTED]>:
Yes. But actually what we would need would be that it checks as well
that we have implemented at *most* a minimal set of operations.
Otherwise, we are back to the point where I can implement both (==) and
(/=), and in a way that the sup
[EMAIL PROTECTED] wrote:
Yes. But actually what we would need would be that it checks as well
that we have implemented at *most* a minimal set of operations.
Otherwise, we are back to the point where I can implement both (==) and
(/=), and in a way that the supposed invariant is broken.
Except
On 10/18/07, Janis Voigtlaender <[EMAIL PROTECTED]> wrote:
> Yes, but that's a problem of the Arrow library writer, not of GHC. The
> compiler will never check a RULE.
I'm going to disagree a bit here; it's not the problem of the Arrow
library writer at all, it's the problem of the implementor of
