Oh! I spoke too soon. Yes, that flag does seem to make unfoldings available. Thanks! Now more experimentation. Thanks again!
-- Conal On Sun, Jan 17, 2016 at 10:45 PM, Conal Elliott <co...@conal.net> wrote: > Thanks for the suggestion. That flag doesn't appear to help. Still no > unfolding info. > > On Sun, Jan 17, 2016 at 10:37 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > >> 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 <allber...@gmail.com> >> > wrote: >> > >> > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott <co...@conal.net> >> 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 >> > > allber...@gmail.com >> > > ballb...@sinenomine.net >> > > unix, openafs, kerberos, infrastructure, xmonad >> > > http://sinenomine.net >> > > >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
