<div dir="ltr">evan, could you share a minimal example of the code that illustrates your problem? It may be that theres <div>a) an alternative way to write it that that gives the perf characteristics you want</div><div style>

b) it could be a good example for future ghc optimization efforts</div><div style>c) other</div><div style><br></div><div style>-Carter</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 18, 2014 at 7:14 PM, Evan Laforge <span dir="ltr"><<a href="mailto:qdunkan@gmail.com" target="_blank">qdunkan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I have a large CAF which is expensive to generate.  Theoretically<br>
it should be possible to totally evaluate at compile time, resulting<br>
in a bunch of constructor calls, ideally totally de-thunked and in the<br>
read-only segment of the binary.<br>
<br>
In the absence of a "eval at compile time" pragma, it seemed like TH<br>
should be able to do this, and searching haskell-cafe I turned up an<br>
old post by Wren where he is doing basically that, and eventually<br>
discovered the Lift class in<br>
<a href="http://hackage.haskell.org/package/template-haskell-2.8.0.0/docs/Language-Haskell-TH-Syntax.html" target="_blank">http://hackage.haskell.org/package/template-haskell-2.8.0.0/docs/Language-Haskell-TH-Syntax.html</a><br>


<br>
However, if I understand Lift correctly (and not really understanding<br>
much of TH), you need to create instances for every type you wish to<br>
generate, which seems like it would be a pain.  Even if they can be<br>
automatically derived, it would spread TH dependency gunk throughout<br>
the whole program.  Is this true?  Is there a library that does the<br>
equivalent of a "eval at compile time" pragma? (Wren's proposed QAF<br>
library seems to have never made it to hackage, but maybe given Lift<br>
and the proper instances it turns out to be trivial.)  Would it be<br>
possible or desirable for an actual pragma that wouldn't introduce a<br>
TH dependency?<br>
<br>
Also, I assume it would produce a giant set of constructor<br>
applications which ghc would then optimize as well as it can...  but<br>
it seems like that might not include full strictness, since even 'x =<br>
(4, undefined)' is obliged to not diverge as long as you don't look at<br>
the snd field, so even a large literal expression is actually<br>
unevaluated code if there are some non-strict data types in there.<br>
<br>
And... is it actually possible for ghc to do clever optimization with<br>
constant values, i.e. lay them out fully evaluated in read-only<br>
memory?  I know that something like 'x = "abc" ++ "def"' will wind up<br>
as 'unpackCString# "abcdef"', but I'm curious what happens to more<br>
complicated data structures.  Strictness seems to make a difference,<br>
e.g. with nonstrict fields the core has separate bindings for the<br>
contained values, while with strict ones the values get inlined<br>
directly into the consumer of the data type and the constructor is<br>
nowhere to be seen.  But if the type is recursive (data X = X Int<br>
(Maybe X)), then we wind up with CAFs applying it, though they have<br>
lots of provocative flags that indicate ghc knows it's dealing with<br>
constructors:<br>
<br>
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True,<br>
         ConLike=True, WorkFree=False, Expandable=True,<br>
         Guidance=IF_ARGS [] 10 30}]<br>
<br>
I assume it still can't hoist the undefined to the entire expression<br>
though, because of non-strictness.  I would think that if all data<br>
types are strict, then it could transform 'caf = X 42 (StrictJust (X<br>
24 undefined))' to 'caf = undefined', but that doesn't seem to happen<br>
either.<br>
<br>
Tangentially, I've noticed that the 'unpackCString# "abcdef"'<br>
optimization is limited to String, replacing it with Text produces<br>
"abc" + giant wodge of code that is presumably appending "def" at<br>
runtime.  I'm sure I've seen some discussions around here about<br>
wanting to optimize string literals to 'Text 0 len (giant chunk of<br>
binary data)', but I don't think they talked about possible compile<br>
time evaluation... presumably it could also solve that problem?<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>