On Mon, Sep 24, 2012 at 5:53 AM, George Giorgidze <span dir="ltr"><<a href="mailto:giorgidze@gmail.com" target="_blank">giorgidze@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1gs">Our second approach to OverloadedLists is to avoid the construction of<br>
lists altogether. By typechecking and desugaring lists like<br>
<br>
[] ; [x,y,z] ; ['a' .. 'z'] ;<br>
<br>
as<br>
<br>
mempty ; singleton x `mappend` singleton y `mappend` singleton z ;<br>
genericEnumFromTo 'a' 'z' ;<br></div></blockquote></div><div><br></div><div>This is very interesting.</div><div><br></div><div>As Michael mentions later, we already have mechanisms in place to work around the creation of constant strings for the Text and ByteString types, and they rely on a combination of GHC rewrite rules and knowledge about the internal representation of constant strings used by GHC. We are fortunate that GHC uses a very efficient representation to store constant strings, so doing the translation is efficient.</div>
<div><br></div><div>Constant lists are another story entirely (for good reason); the generated object files are bloated and poorly laid out, when for simple types (integers and whatnot), I'd really like to see a packed array in the .data section.</div>
<div><br></div><div>I would be interested to see if an approach that avoids list construction can also aim to achieve a more efficient object file layout, with the implied goal being to make fast translation to the runtime representation easily achievable.</div>