Is there a reason why any/all of the data types in Language.Haskell.THSyntax (such as Dec, Stmt, and Type) don't derive Eq? I'm thinking that it would be useful for test suites, in particular. -- % Andre Pang : trust.in.love.to.save
On Saturday 09 August 2003 3:58 pm, Andre Pang wrote:
Is there a reason why any/all of the data types in Language.Haskell.THSyntax (such as Dec, Stmt, and Type) don't derive Eq? I'm thinking that it would be useful for test suites, in particular.
I recently found myself wanting that. The tricky one is Eq for types that contain forall. The derived instances would be wrong if we want to allow alpha conversion. Hand-writing a correct instance is pretty tedious. -- Alastair
On Wed, Aug 13, 2003 at 12:14:32AM +0100, Alastair Reid wrote:
On Saturday 09 August 2003 3:58 pm, Andre Pang wrote:
Is there a reason why any/all of the data types in Language.Haskell.THSyntax (such as Dec, Stmt, and Type) don't derive Eq? I'm thinking that it would be useful for test suites, in particular.
I recently found myself wanting that.
The tricky one is Eq for types that contain forall. The derived instances would be wrong if we want to allow alpha conversion.
This opens up the issue of how much difference should be allowed in things before they stop being equal, e.g. should "Let ds1 in e" and "Let ds2 in e" be equal if they have the same statements in a different order? What about alpha renaming of variables in expressions? It doesn't take many acceptable differences before it starts to get rather complicated, not to mention confusing to the user when some differences are accepted but others aren't. I think the best choice is that two datastructures are equal (==) iff they are identical.
Hand-writing a correct instance is pretty tedious.
Write it with TH then :-) Ian
On Wed, 13 Aug 2003, Ian Lynagh wrote:
This opens up the issue of how much difference should be allowed in things before they stop being equal, e.g. should "Let ds1 in e" and "Let ds2 in e" be equal if they have the same statements in a different order? What about alpha renaming of variables in expressions? It doesn't take many acceptable differences before it starts to get rather complicated, not to mention confusing to the user when some differences are accepted but others aren't.
I think the best choice is that two datastructures are equal (==) iff they are identical.
That's certainly the simplest solution but I'm not convinced it's the best. Couldn't you simply write a "canonical-ise" function which takes an expression and puts it into some sort of canonical form and then tests for equality. However, there are many issues to consider like you said. Eta-reduction would another to think about. Sean
On Wed, Aug 13, 2003 at 10:37:05AM +1000, Sean Seefried wrote:
On Wed, 13 Aug 2003, Ian Lynagh wrote:
This opens up the issue of how much difference should be allowed in things before they stop being equal, e.g. should "Let ds1 in e" and "Let ds2 in e" be equal if they have the same statements in a different order? What about alpha renaming of variables in expressions? It doesn't take many acceptable differences before it starts to get rather complicated, not to mention confusing to the user when some differences are accepted but others aren't.
I think the best choice is that two datastructures are equal (==) iff they are identical.
That's certainly the simplest solution but I'm not convinced it's the best. Couldn't you simply write a "canonical-ise" function which takes an expression and puts it into some sort of canonical form and then tests for equality. However, there are many issues to consider like you said. Eta-reduction would another to think about.
Ultimately you hit the undecidability of the equivalence of Haskell expressions. The principle of least surprise suggests to me going for the other extreme rather than trying to find the best spot in the middle. This is useful for "Has this changed after I applied a function to it?" but not "Are these definitely the same?" which I think are the two generally useful functions. It's also the easier to implement and the more efficient of the two. Thanks Ian
participants (4)
-
Alastair Reid -
Andre Pang -
Ian Lynagh -
Sean Seefried