Re: Containers and strictness

this all sounds like wonderful work, looking forward to it. slightly off topic, but in whatever revision of Data.IntMap you come up with, can you include foldrWithKey, toDescList, mapAccumRWithKey and the rest of the reverse-order traversals which are in Data.Map? all for consistency..... best regards, ben On Thu, Jun 24, 2010 at 9:00 AM, wrote:

Send Libraries mailing list submissions to        libraries@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit        http://www.haskell.org/mailman/listinfo/libraries or, via email, send a message with subject or body 'help' to        libraries-request@haskell.org

You can reach the person managing the list at        libraries-owner@haskell.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Libraries digest..."

Today's Topics:

  1. Re: Containers and strictness (Edward Kmett)   2. Re: Containers and strictness (Johan Tibell)

----------------------------------------------------------------------

Message: 1 Date: Thu, 24 Jun 2010 09:28:15 -0400 From: Edward Kmett Subject: Re: Containers and strictness To: Johan Tibell Cc: Duncan Coutts ,        libraries@haskell.org Message-ID:         Content-Type: text/plain; charset="utf-8"

On Thu, Jun 24, 2010 at 8:27 AM, Johan Tibell wrote:

...

On Thu, Jun 24, 2010 at 1:59 PM, Edward Kmett wrote:

...

2010/6/24 Milan Straka

...

On 24 June 2010 11:14, Milan Straka wrote:

...

...

I need some opinion:

- Do you think methods like insert/lookup/delete/etc should be strict

in

...

...

 key/element?

 As Claus wrote, right now it is undocumented and inconsistent (both in  the methods of one container and also in the same methods of different  container).

Just as it is sometimes important to be able to do strict inserts, it is important sometimes that we have maps that are lazy in the elements. There are important use cases both ways.

So yes we should have some kind of consistent convention. We could do worse than the naming convention where the strict versions use a trailing prime ' character.

I thought we are talking only about keys/elements. I would leave the values untouched.

Personally I vote for: - keys in Maps and elements in Sets are strict - vales in Maps are left untouched (lazy)

+1 from me

Great work so far.

The space overhead per key/value pair is 6 words (48 bytes on a 64-bit architecture) when using lazy values but only 4 words (32 bytes) per key/value pair when using strict (unpacked) values, a 50% difference. This really starts to matter with big enough data sets (as seen in the recent Twitter analysis thread). When work with Big Data it's often desirable to fit as much data in RAM as possible as the result of many algorithms (think machine learning or search ranking) differs with the amount of data you can hold in memory.

Something to consider.

I definitely agree that unboxing can help a great deal with performance and space utilization.

However, as containers does not currently require any exotic extensions, I think that perhaps a type family -based generic map would belong in another 'unboxed-containers' or 'adaptive-containers' package (both of which currently exist on hackage), as it dramatically extends the language extension footprint of containers, taking it from something that easily runs across a wide array of Haskell implementations to something very ghc-specific.

-Edward Kmett