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.)
On Mon, Jan 18, 2016 at 9:46 AM, Conal Elliott <[email protected]> wrote: > 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? > > And Happy Birthday, Simon! > > Warmly, - Conal > > > On Monday, January 18, 2016, Simon Peyton Jones <[email protected]> > wrote: > >> Or -fexpose-all-unfoldings? >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:[email protected]] On Behalf Of >> | Edward Z. Yang >> | Sent: 18 January 2016 06:37 >> | To: Conal Elliott <[email protected]> >> | Cc: Andrew Farmer <[email protected]>; [email protected] >> | Subject: Re: ghci and unfoldings? >> | >> | Does passing -fobject-code solve your problem? >> | >> | Edward >> | >> | Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800: >> | > Hi Brandon. Thanks for the reply. I’m not sure that it addresses >> | what >> | > I was trying to ask. GHCi *does* invoke plugins and even reloads >> | those >> | > plugins dynamically when their source code changes. So in this sense >> | > ghci does enable optimization, even if it doesn’t perform much >> | > optimization on its own. And of course plugins and unfolding are not >> | just about optimization. >> | > >> | > I’m not looking for ghci to do optimization, but rather to enable me >> | > to more easily develop my GHC plugins. It’s *almost* there already. >> | I >> | > just need access to unfoldings from other modules for my plugin’s >> | use. >> | > >> | > For context, I’m rebuilding my Haskell-to-hardware compiler >> | > <https://github.com/conal/talk-2015-haskell-to-hardware>, which >> | relies >> | > on giving a non-standard but principled interpretation of Haskell >> | > programs via a conversion through the language of cartesian closed >> | categories (CCCs). >> | > The first back-end is hardware generation (e.g., via Verilog), and I >> | > have plans for several other CCC-based interpretations. >> | > >> | > In addition to facilitating my plugin development, hosting in ghci >> | > will make it much more pleasant for others to *use* the plugin >> | during >> | > exploratory programming, just as with ghci use in general. With >> | access >> | > to unfoldings, users will be able to generate circuit diagrams and >> | > Verilog like those in my compiler talk immediately and directly from >> | > within ghci. I also intend to make a GPU back-end for fast >> | interactive >> | > graphics etc, which would be much more fun in ghci than with batch >> | compilation. >> | > I hope this explanation clarifies my goals and motivation. I hope >> | > there’s a way to access unfoldings from ghci currently or with a >> | small >> | > amount of effort. >> | > >> | > Regards, - Conal >> | > >> | > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery >> | <[email protected]> >> | > wrote: >> | > >> | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott <[email protected]> >> | wrote: >> | > > >> | > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use >> | > >> ghci to speed up development. I'm able to do so, except that my >> | > >> plugin critically needs access to unfoldings, which appear to be >> | > >> unavailable in ghci. A little experimenting with ghc shows me >> | that >> | > >> "-O" is the key, but "-O" is incompatible with "--interactive" >> | (as >> | > >> in ghci). Is there any way to persuade ghci to make unfoldings >> | available? >> | > > >> | > > >> | > > I think unfoldings are only done as part of optimization, and the >> | > > bytecode backend doesn't support optimization at all. >> | > > >> | > > -- >> | > > brandon s allbery kf8nh sine nomine >> | > > associates >> | > > [email protected] >> | > > [email protected] >> | > > unix, openafs, kerberos, infrastructure, xmonad >> | > > >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine >> | > > >> | nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 >> | > > >> | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda >> | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d >> | > > >> | _______________________________________________ >> | ghc-devs mailing list >> | [email protected] >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h >> | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af >> | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=veoz >> | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d >> >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
