<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<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>