ghci and unfoldings?

Tue Jan 19 14:07:05 UTC 2016

-fno-ignore-interface-pragmas might work.  However the problem is really
that the interpreter cannot compile the full intermediate language of GHC
(it can't handle arbitrary unboxed tuples), and we work around that in a
fairly fragile way by disabling -O.  By enabling unfoldings you might
expose the interpreter to some unboxed tuples which would cause it to
panic.  It's unlikely this will get fixed in the near term, if I recall
correctly it's pretty hard to fix.

So I think the best fix is probably to use -fobject-code.

Cheers,
Simon

On 18 January 2016 at 18:28, Conal Elliott <conal at conal.net> wrote:

> 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
>>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160119/4a5a41e7/attachment.html>