Christian Maeder wrote:
2) Eq e is some equivalence relation, such as in Christian's example above.
This is more often the case than one might like. Even for the type Set itself Eq/Ord can be observed differently by the debugging function showTree.
Yes. Let me refine where I picture the border of Good Use of Eq. Eq should implement *conceptual* (semantic) equality. Haskell objects are often not in one-to-one correspondence with the conceptual object they represent: there may be many trees that represent the same set. When you're defining a set, you consider those trees equal and that should be reflected in your Eq instance.
users should always use a Map instead (e.g. Map Symbol Position, with 'real equality' on Symbol).
if I have:
data Symbol = Symbol String Position instance Eq/Ord Symbol -- compare String only
I'd rather like "Map Symbol Position" than "Map String Position" if I want to be more explicit about positions.
In this case I would go for something like ] data Symbol = Symbol String ] instance Eq/Ord Symbol so you *can* say "Map Symbol Position". IMO this better reflects what a symbol 'is'. One might want to add ] type Occurrence = (Symbol,Position) or even ] type Occurrence = MapElement Symbol Position
Controlled bias is simply an additional benefit of the Data.Set library implementation that you must not and are not encouraged to use (but that may be helpful if you know what you are doing),
Agreed. Greetings, Arie