Re: Proposal: add Int indexing functions to Data.Set

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@gmail.com> wrote:

On 29 April 2011 16:08, Luis Casillas 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@gmail.com IvanMiljenovic.wordpress.com

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries