<div dir="ltr"><div><div>-fno-ignore-interface-pragmas might work.  However the problem is really that the interpreter cannot compile the full intermediate language of GHC (it can't handle arbitrary unboxed tuples), and we work around that in a fairly fragile way by disabling -O.  By enabling unfoldings you might expose the interpreter to some unboxed tuples which would cause it to panic.  It's unlikely this will get fixed in the near term, if I recall correctly it's pretty hard to fix.<br><br>So I think the best fix is probably to use -fobject-code.<br><br></div>Cheers,<br></div>Simon<br><div><div><br> </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 January 2016 at 18:28, Conal Elliott <span dir="ltr"><<a href="mailto:conal@conal.net" target="_blank">conal@conal.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The minimum flags I've found to get ghci to provide unfoldings are -O and -object-code. And it appears that both flags need to be present the first time I load a module into GHCi. (I'm putting the flags in an OPTIONS_GHC pragma.)<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 18, 2016 at 9:46 AM, Conal Elliott <span dir="ltr"><<a href="mailto:conal@conal.net" target="_blank">conal@conal.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>That's the flag I would expect. It doesn't seem to help or hinder availability of unfoldings in GHCi. Do you think it should?<br><br></div>And Happy Birthday, Simon!<br><br></div>Warmly, - Conal<div><div><br><div><div><br>On Monday, January 18, 2016, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Or -fexpose-all-unfoldings?<br>
<br>
Simon<br>
<br>
|  -----Original Message-----<br>
|  From: ghc-devs [mailto:<a>ghc-devs-bounces@haskell.org</a>] On Behalf Of<br>
|  Edward Z. Yang<br>
|  Sent: 18 January 2016 06:37<br>
|  To: Conal Elliott <<a>conal@conal.net</a>><br>
|  Cc: Andrew Farmer <<a>afarmer@ittc.ku.edu</a>>; <a>ghc-devs@haskell.org</a><br>
|  Subject: Re: ghci and unfoldings?<br>
|<br>
|  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>
|  > Hi Brandon. Thanks for the reply. I’m not sure that it addresses<br>
|  what<br>
|  > I was trying to ask. GHCi *does* invoke plugins and even reloads<br>
|  those<br>
|  > plugins dynamically when their source code changes. So in this sense<br>
|  > ghci does enable optimization, even if it doesn’t perform much<br>
|  > optimization on its own. And of course plugins and unfolding are not<br>
|  just about optimization.<br>
|  ><br>
|  > I’m not looking for ghci to do optimization, but rather to enable me<br>
|  > to more easily develop my GHC plugins. It’s *almost* there already.<br>
|  I<br>
|  > just need access to unfoldings from other modules for my plugin’s<br>
|  use.<br>
|  ><br>
|  > For context, I’m rebuilding my Haskell-to-hardware compiler<br>
|  > <<a href="https://github.com/conal/talk-2015-haskell-to-hardware" target="_blank">https://github.com/conal/talk-2015-haskell-to-hardware</a>>, which<br>
|  relies<br>
|  > on giving a non-standard but principled interpretation of Haskell<br>
|  > programs via a conversion through the language of cartesian closed<br>
|  categories (CCCs).<br>
|  > The first back-end is hardware generation (e.g., via Verilog), and I<br>
|  > have plans for several other CCC-based interpretations.<br>
|  ><br>
|  > In addition to facilitating my plugin development, hosting in ghci<br>
|  > will make it much more pleasant for others to *use* the plugin<br>
|  during<br>
|  > exploratory programming, just as with ghci use in general. With<br>
|  access<br>
|  > to unfoldings, users will be able to generate circuit diagrams and<br>
|  > Verilog like those in my compiler talk immediately and directly from<br>
|  > within ghci. I also intend to make a GPU back-end for fast<br>
|  interactive<br>
|  > graphics etc, which would be much more fun in ghci than with batch<br>
|  compilation.<br>
|  > I hope this explanation clarifies my goals and motivation. I hope<br>
|  > there’s a way to access unfoldings from ghci currently or with a<br>
|  small<br>
|  > amount of effort.<br>
|  ><br>
|  > Regards, - Conal<br>
|  ><br>
|  > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery<br>
|  <<a>allbery.b@gmail.com</a>><br>
|  > wrote:<br>
|  ><br>
|  > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott <<a>conal@conal.net</a>><br>
|  wrote:<br>
|  > ><br>
|  > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use<br>
|  > >> ghci to speed up development. I'm able to do so, except that my<br>
|  > >> plugin critically needs access to unfoldings, which appear to be<br>
|  > >> unavailable in ghci. A little experimenting with ghc shows me<br>
|  that<br>
|  > >> "-O" is the key, but "-O" is incompatible with "--interactive"<br>
|  (as<br>
|  > >> in ghci). Is there any way to persuade ghci to make unfoldings<br>
|  available?<br>
|  > ><br>
|  > ><br>
|  > > I think unfoldings are only done as part of optimization, and the<br>
|  > > bytecode backend doesn't support optimization at all.<br>
|  > ><br>
|  > > --<br>
|  > > brandon s allbery kf8nh                               sine nomine<br>
|  > > associates<br>
|  > > <a>allbery.b@gmail.com</a><br>
|  > > <a>ballbery@sinenomine.net</a><br>
|  > > unix, openafs, kerberos, infrastructure, xmonad<br>
|  > ><br>
|  <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine</a><br>
|  > ><br>
|  <a href="http://nomine.net" target="_blank">nomine.net</a>&data=01%7c01%7csimonpj%<a href="http://40064d.mgd.microsoft.com" target="_blank">40064d.mgd.microsoft.com</a>%7cbaf2ef5<br>
|  > ><br>
|  5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda<br>
|  > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d<br>
|  > ><br>
|  _______________________________________________<br>
|  ghc-devs mailing list<br>
|  <a>ghc-devs@haskell.org</a><br>
|  <a href="https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h" target="_blank">https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h</a><br>
|  <a href="http://askell.org" target="_blank">askell.org</a>%2fcgi-bin%2fmailman%2flistinfo%2fghc-<br>
|  devs%0a&data=01%7c01%7csimonpj%<a href="http://40064d.mgd.microsoft.com" target="_blank">40064d.mgd.microsoft.com</a>%7cbaf2ef55f8af<br>
|  447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz<br>
|  Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d<br>
</blockquote>
</div></div></div></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>