semantics of Eq instance for Var.Var (was: is shadowing allowed in CoreSyn?)

[Adam Megacz]

Max Bolingbroke <batterseapower at hotmail.com> writes:
>> Hrm, isn't it bad for two Var's with different fields to have the same
>> uniq?  Because if they have the same uniq, they will be Eq-equal.
>
> Just because two vars are eq-equal does not mean that they refer to
> the "same thing".

Hrm, okay, thanks for clearing this up... but, in that case,  what
exactly does it mean for two Vars to be Eq-equal?

Technically according to the code, two Vars are equal if they have the
same Unique.  But if I understand correctly, Uniques are just supposed
to be a way of making some other equivalence test go faster by picking a
canonical representative (the Unique) for each equivalence class of the
relation (from the Haddock: "[Unique is] the type of unique identifiers
that are used in many places in GHC for fast ordering and equality tests").

So, in this case, what equivalence test is being made faster?

A Var is basically an OccName plus a Type, but:

  - Two Vars with the same OccName may be unequal (I see why this is)

  - Two Vars with different types may be equal

  - Two Vars which represent variables which have different binding
    sites may be equal (which is what I understand 'refer to the "same
    thing"' to mean).

So I guess I'm confused about what equality on Vars is supposed to mean.
How would you write "instance Eq Var" if you didn't care about fast
ordering and equality tests and therefore weren't using Uniques?

Sorry to be so pedantic about this; I just want to get it right.

  - a