<div dir="ltr">Thanks for the suggestion. That flag doesn't appear to help. Still no unfolding info.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 17, 2016 at 10:37 PM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does passing -fobject-code solve your problem?<br>
<br>
Edward<br>
<br>
Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:<br>
<span class="">> Hi Brandon. Thanks for the reply. I’m not sure that it addresses what I was<br>
</span>> trying to ask. GHCi *does* invoke plugins and even reloads those plugins<br>
<span class="">> dynamically when their source code changes. So in this sense ghci does<br>
> enable optimization, even if it doesn’t perform much optimization on its<br>
> own. And of course plugins and unfolding are not just about optimization.<br>
><br>
> I’m not looking for ghci to do optimization, but rather to enable me to<br>
</span>> more easily develop my GHC plugins. It’s *almost* there already. I just<br>
<span class="">> need access to unfoldings from other modules for my plugin’s use.<br>
><br>
> For context, I’m rebuilding my Haskell-to-hardware compiler<br>
</span>> <<a href="https://github.com/conal/talk-2015-haskell-to-hardware" rel="noreferrer" target="_blank">https://github.com/conal/talk-2015-haskell-to-hardware</a>>, which relies on<br>
<span class="">> giving a non-standard but principled interpretation of Haskell programs via<br>
> a conversion through the language of cartesian closed categories (CCCs).<br>
> The first back-end is hardware generation (e.g., via Verilog), and I have<br>
> plans for several other CCC-based interpretations.<br>
><br>
> In addition to facilitating my plugin development, hosting in ghci will<br>
</span>> make it much more pleasant for others to *use* the plugin during<br>
<div class="HOEnZb"><div class="h5">> exploratory programming, just as with ghci use in general. With access to<br>
> unfoldings, users will be able to generate circuit diagrams and Verilog<br>
> like those in my compiler talk immediately and directly from within ghci. I<br>
> also intend to make a GPU back-end for fast interactive graphics etc, which<br>
> would be much more fun in ghci than with batch compilation.<br>
> I hope this explanation clarifies my goals and motivation. I hope there’s a<br>
> way to access unfoldings from ghci currently or with a small amount of<br>
> effort.<br>
><br>
> Regards, - Conal<br>
><br>
> On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>><br>
> wrote:<br>
><br>
> > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott <<a href="mailto:conal@conal.net">conal@conal.net</a>> wrote:<br>
> ><br>
> >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to<br>
> >> speed up development. I'm able to do so, except that my plugin critically<br>
> >> needs access to unfoldings, which appear to be unavailable in ghci. A<br>
> >> little experimenting with ghc shows me that "-O" is the key, but "-O" is<br>
> >> incompatible with "--interactive" (as in ghci). Is there any way to<br>
> >> persuade ghci to make unfoldings available?<br>
> ><br>
> ><br>
> > I think unfoldings are only done as part of optimization, and the bytecode<br>
> > backend doesn't support optimization at all.<br>
> ><br>
> > --<br>
> > brandon s allbery kf8nh                               sine nomine<br>
> > associates<br>
> > <a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a><br>
> > <a href="mailto:ballbery@sinenomine.net">ballbery@sinenomine.net</a><br>
> > unix, openafs, kerberos, infrastructure, xmonad<br>
> > <a href="http://sinenomine.net" rel="noreferrer" target="_blank">http://sinenomine.net</a><br>
> ><br>
</div></div></blockquote></div><br></div>