Using Ord for keys of maps and sets
Henning Thielemann wrote:
I already told about by scepticism about using Ord for keys of maps and sets: http://www.haskell.org/pipermail/libraries/2007-April/007411.html
Yes. There are a number of different scenarios for the ordering that you want to use for indexing: 1. A default ordering for the type that is a natural ordering. 2. A default ordering for indexing that is not a natural ordering. 3. An application-specific ordering. 4. More than one ordering for the same type, determined statically. 5. More than one ordering for the same type, determined dynamically, i.e., parameterized orderings. My experience has been that all of these cases do come up quite often in real life. One solution would be to have Data.Map.Indexable, etc. as alternatives using Indexable instead of Ord, so that we could avoid newtype wrapping in case 2. We could allow for case 3 by not providing any default instances for Indexable. Or we could provide default instances in a separate module, Data.Indexable.Instances (or something), that you could choose whether or not to import. Newtype wrapping is still required in case 4, so Indexable doesn't add much here. We have not yet said anything helpful about case 5. -Yitz
On Mon, 3 Dec 2007, Yitzchak Gale wrote:
Henning Thielemann wrote:
I already told about by scepticism about using Ord for keys of maps and sets: http://www.haskell.org/pipermail/libraries/2007-April/007411.html
Yes. There are a number of different scenarios for the ordering that you want to use for indexing:
1. A default ordering for the type that is a natural ordering.
2. A default ordering for indexing that is not a natural ordering.
3. An application-specific ordering.
4. More than one ordering for the same type, determined statically.
5. More than one ordering for the same type, determined dynamically, i.e., parameterized orderings.
My experience has been that all of these cases do come up quite often in real life.
One solution would be to have Data.Map.Indexable, etc. as alternatives using Indexable instead of Ord, so that we could avoid newtype wrapping in case 2.
We could allow for case 3 by not providing any default instances for Indexable.
This would obstruct 'start GHCi and play around' sessions, since you cannot create a set of something on the fly. (However, GHCi could still be adapted.)
Or we could provide default instances in a separate module, Data.Indexable.Instances (or something), that you could choose whether or not to import.
Newtype wrapping is still required in case 4, so Indexable doesn't add much here.
We have not yet said anything helpful about case 5.
Still, later in the above thread, Johannes Waldmann throws in Local Instances: http://www.haskell.org/pipermail/libraries/2007-April/007416.html
I wrote:
We could allow for case 3 by not providing any default instances for Indexable.
Henning Thielemann wrote:
This would obstruct 'start GHCi and play around' sessions, since you cannot create a set of something on the fly. (However, GHCi could still be adapted.)
Yes. I am suggesting also leaving the current versions that use Ord, so we are no worse off with that than we were before, at least.
Still, later in the above thread, Johannes Waldmann throws in Local Instances: http://www.haskell.org/pipermail/libraries/2007-April/007416.html
Ah, yes. That would be great! I would especially like it for GHCI - in general, not just because of the special case you mentioned above. But this has come up before. There are people who are not sure about this feature, because of some ambiguous and/or confusing cases that can come up when you redefine an instance that already exists in an enclosing context. And anyway - this is a serious language change. It will at best take time. Your Indexable class could be used right now to make a lot of the most common cases much easier to handle. -Yitz
participants (2)
-
Henning Thielemann -
Yitzchak Gale