ghci and unfoldings?

[Conal Elliott]

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 <conal at conal.net> 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 <simonpj at microsoft.com>
> wrote:
>
>> Or -fexpose-all-unfoldings?
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> |  Edward Z. Yang
>> |  Sent: 18 January 2016 06:37
>> |  To: Conal Elliott <conal at conal.net>
>> |  Cc: Andrew Farmer <afarmer at ittc.ku.edu>; ghc-devs at haskell.org
>> |  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
>> |  <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
>> |  > >
>> |  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
>> |  ghc-devs at haskell.org
>> |  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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160118/92be22a5/attachment.html>