Point being, I think your pointing to an idea other people are (also) interested in exploring for ghc, and that there's some interesting subltelties to it. <span></span><br><br>On Saturday, January 18, 2014, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You ask for something that ghc doesnt have yet, but perhaps could have at some point. (If I'm reading you right).  Currently ghc doesn't have a way of doing what you want! Eg, I don't think there's even really support as yet for that sort of notion in the context of just boxed/unboxed/storable arrays.  <div>

<br></div><div>There's definitely a few example pieces of code here it'd be nice to express a read only lookup array that's fixed before run time for various bit fiddling etc algs. <span></span><br><br>On Saturday, January 18, 2014, Evan Laforge <<a href="javascript:_e({}, 'cvml', 'qdunkan@gmail.com');" target="_blank">qdunkan@gmail.com</a>> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Jan 18, 2014 at 4:56 PM, adam vogt <<a>vogt.adam@gmail.com</a>> wrote:<br>

> Check out <<a href="https://hackage.haskell.org/package/th-lift" target="_blank">https://hackage.haskell.org/package/th-lift</a>>. Also, there<br>
> is a of zeroTH here <a href="https://github.com/mgsloan/zeroth" target="_blank">https://github.com/mgsloan/zeroth</a> which works with<br>
> a haskell-src-exts < 1.14.<br>
<br>
Thanks, I'll take a look.  Though since I have my faster-but-uglier<br>
solution, at this point I'm mostly only theoretically interested, and<br>
hoping to learn something about compilers and optimization :)<br>
<br>
> I'm not sure what benefit you'd get from a new mechanism (beside TH)<br>
> to calculate things at compile-time. Won't it have to solve the same<br>
> problems which are solved by TH already? How can those problems<br>
> (generating haskell code, stage restriction) be solved without ending<br>
> up with the same kind of complexity ("TH dependency gunk")?<br>
<br>
Well, TH is much more powerful in that it can generate any expression<br>
at compile time.  But in exchange, it slows down compilation a lot,<br>
introduces an order dependency in the source file, and causes<br>
complications for the build system (I don't remember exactly, but it<br>
came down to needing to find the .o files at compile time).  I would<br>
think, in the handwaviest kind of way, that the compiler could compile<br>
a CAF, and then just evaluate it on the spot by just following all the<br>
code thunk pointers (similar to a deepseq), and then emit the raw data<br>
structure that comes out.  Of course that assumes that there is a such<br>
thing as "raw" data, which is why I got all side tracked wondering<br>
about compile time optimization in general.  I expect it's not like C<br>
where you would wind up with a nested bunch of structs you could just<br>
write directly to the .TEXT section of the binary and then mmap into<br>
place when the binary is run.  Even in C you'd need to go fix up<br>
pointers.  At which point it sounds like a dynamic loader :)<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a>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>
</blockquote>