ghci and unfoldings?

[Conal Elliott]

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 <conal at 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 <ezyang at 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 <allbery.b at gmail.com>
>> > wrote:
>> >
>> > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott <conal at 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
>> > > allbery.b at gmail.com
>> > > ballbery at sinenomine.net
>> > > unix, openafs, kerberos, infrastructure, xmonad
>> > > http://sinenomine.net
>> > >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160117/d5317773/attachment.html>