[Template-haskell] Language.Haskell.THSyntax data types deriving Eq

[Simon Peyton-Jones]

I rather agree with Ian on this point.  Ian, if you want to go ahead and
implement your suggestion, that's fine with me.

Incidentally, I've been quiet on the TH front because (a) I've been on
holiday, (b) I'm deeply immersed in a reworking of the typecheck/renamer
which should make it much easier to implement type splices (as well as
being generally more wonderful).  Now it's time for ICFP, then catching
up, then I'll be back in business.

Meanwhile, it'd be useful if any of you who are actively using TH would
identify your top priorities for changes/fixes/improvements.   If there
is a consensus on what's important, I'm much more likely to do something
about it!  You can post your priority list to this mailing list.  Even
better if accompanied with volunteering to help do it.

Simon

| -----Original Message-----
| From: template-haskell-admin@haskell.org
[mailto:template-haskell-admin@haskell.org] On Behalf Of
| Ian Lynagh
| Sent: 13 August 2003 02:08
| To: template-haskell@haskell.org
| Subject: Re: [Template-haskell] Language.Haskell.THSyntax data types
deriving Eq
|=20
| 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 =
(=3D=3D)
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.
|=20
| 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.
|=20
| 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.
|=20
|=20
| Thanks
| Ian
|=20
| _______________________________________________
| template-haskell mailing list
| template-haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/template-haskell