Proposal: add Int indexing functions to Data.Set

[Balazs Komuves]

Isn't for example "elemAt k someMapOrSet" equivalent (but much faster) to
"(toList someMapOrSet) !! k",
and similarly for all the other index functions? So how does it break any
abstraction?

While I have to agree (referring to the old discussion) that the Map/Set API
is far from perfect,
I'm much more in favour of exposing efficient functionality than removing
useful stuff...

Regards,
Balazs

Concern that Int-based indexing breaks the set abstraction by exposing a
> specific ordering (Trac comment by Malcolm Wallace).  My assumption when I
> decided to submit this patch was that if it's OK for Data.Map to have these
> operations, then it should also be ok for Data.Set to have them.
>


On Fri, Apr 29, 2011 at 8:50 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> On 29 April 2011 16:08, Luis Casillas <luis at casillas.org> wrote:
> >
> > El abr 28, 2011, a las 10:42 p.m., Ivan Lazar Miljenovic escribió:
> >
> >> Well, before we talk about modifications, etc.: is there a _need_ for
> >> this kind of indexing in a Set?
> >
> > Well, to take a step back, the reasoning that led me to make this
> proposal is really no better than this:
> >
> > 1. Map already has analogues to the Set functions I'm proposing.
> > 2. There is some good reason why Map should have those functions.
> > 3. Whatever reason that is, it also applies to Set.
> > 4. Ergo, Set should have these functions.
> >
> > It looks to me like you disagree with (2) or (3), and you're the second
> person to do so (out of three who have responded so far).  If the majority
> of responses turn out like this, well, then the case for my proposal is just
> not as strong as I assumed it would be.
>
> Actually, I primarily disagree with 2) ;-)
>
> Maybe we need an alternate proposal: remove index-based functions from
> Data.Map...
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> IvanMiljenovic.wordpress.com
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110429/a1727be2/attachment-0001.htm>