Re: semantics of Eq instance for Var.Var

2011-02-18 Thread Adam Megacz
Roman Leshchinskiy writes: > Two Vars are Eq-equal iff they could shadow each other. Simon Peyton-Jones writes: > Two Vars are considered equal if their Names are the same. Max Bolingbroke writes: > If you weren't using Uniques, presumably your variables would be > compared just by their OccN

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

2011-02-17 Thread Simon Peyton-Jones
| 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

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

2011-02-17 Thread Roman Leshchinskiy
On 17/02/2011, at 00:33, Adam Megacz wrote: > Max Bolingbroke 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

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

2011-02-16 Thread Max Bolingbroke
On 17 February 2011 00:33, Adam Megacz wrote: > 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

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

2011-02-16 Thread Adam Megacz
Max Bolingbroke 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 u