gmane.comp.lang.haskell.libraries

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

(Continue reading)

headers

Henning Thielemann | 3 Dec 14:42

Re: Using Ord for keys of maps and sets


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.

(Continue reading)

headers

Yitzchak Gale | 3 Dec 15:04

Re: Using Ord for keys of maps and sets

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

(Continue reading)