On Thu, Jun 24, 2010 at 8:27 AM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com">johan.tibell@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><div class="gmail_quote">On Thu, Jun 24, 2010 at 1:59 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote">2010/6/24 Milan Straka <span dir="ltr"><<a href="mailto:fox@ucw.cz" target="_blank">fox@ucw.cz</a>></span><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> On 24 June 2010 11:14, Milan Straka <<a href="mailto:fox@ucw.cz" target="_blank">fox@ucw.cz</a>> wrote:<br>
><br>
> > I need some opinion:<br>
> ><br>
> > - Do you think methods like insert/lookup/delete/etc should be strict in<br>
> > key/element?<br>
> ><br>
> > As Claus wrote, right now it is undocumented and inconsistent (both in<br>
> > the methods of one container and also in the same methods of different<br>
> > container).<br>
><br>
> Just as it is sometimes important to be able to do strict inserts, it<br>
> is important sometimes that we have maps that are lazy in the<br>
> elements. There are important use cases both ways.<br>
><br>
> So yes we should have some kind of consistent convention. We could do<br>
> worse than the naming convention where the strict versions use a<br>
> trailing prime ' character.<br>
<br>
</div>I thought we are talking only about keys/elements. I would leave the<br>
values untouched.<br>
<br>
Personally I vote for:<br>
- keys in Maps and elements in Sets are strict<br>
- vales in Maps are left untouched (lazy)<br></blockquote><div><br></div></div><div>+1 from me</div><div><br></div><div>Great work so far.</div></div></blockquote></div><br></div></div>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.<br>
<br>Something to consider.<br></blockquote><div><br>I definitely agree that unboxing can help a great deal with performance and space utilization.<br><br>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.<br>
<br>-Edward Kmett<br></div><br></div>