RE: ghci and unfoldings?
Ah….It seems that to get unfoldings exposed in the module you are compiling you need both · -fno-omit-interface-pragmas · -fexpose-all-unfoldings And GHCi and –O0 both imply –fomit-interface-pragmas. To see the unfoldings on imported functions you need –fno-ignore-interface pragmas. Arguably –fexpose-all-unfoldings should override –fomit-interface-pragmas, which it doesn’t at the moment. Open a ticket if you think that would be useful and important. I can give guidance about the places. Simon From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of Conal Elliott Sent: 18 January 2016 17:47 To: Simon Peyton Jones <simo...@microsoft.com> Cc: Edward Z. Yang <ezy...@mit.edu>; Andrew Farmer <afar...@ittc.ku.edu>; ghc-devs@haskell.org Subject: Re: ghci and unfoldings? 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 <simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote: Or -fexpose-all-unfoldings? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Edward Z. Yang | Sent: 18 January 2016 06:37 | To: Conal Elliott <co...@conal.net<mailto:co...@conal.net>> | Cc: Andrew Farmer <afar...@ittc.ku.edu<mailto:afar...@ittc.ku.edu>>; ghc-devs@haskell.org<mailto:ghc-devs@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 | <allber...@gmail.com<mailto:allber...@gmail.com>> | > wrote: | > | > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott <co...@conal.net<mailto: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<mailto:allber...@gmail.com> | > > ballb...@sinenomine.net<mailto:ballb...@sinenomine.net> | > > unix, openafs, kerberos, infrastructure, xmon
Re: ghci and unfoldings?
-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 <co...@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 <co...@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 <simo...@microsoft.com> >> wrote: >> >>> Or -fexpose-all-unfoldings? >>> >>> Simon >>> >>> | -Original Message- >>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of >>> | Edward Z. Yang >>> | Sent: 18 January 2016 06:37 >>> | To: Conal Elliott <co...@conal.net> >>> | Cc: Andrew Farmer <afar...@ittc.ku.edu>; ghc-devs@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 >>> | <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 >>>
Re: ghci and unfoldings?
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 <simo...@microsoft.com> wrote: > Or -fexpose-all-unfoldings? > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Edward Z. Yang > | Sent: 18 January 2016 06:37 > | To: Conal Elliott <co...@conal.net> > | Cc: Andrew Farmer <afar...@ittc.ku.edu>; ghc-devs@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 > | <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 > | > > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine > | > > > | nomine.net=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef5 > | > > > | 5f8af447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1 > | > > ta=qMNmL5LmkgMp0ebkr6SzPQIwhySqOicZgEdW%2fhe6Q%2b0%3d > | > > > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs%0a=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cbaf2ef55f8af > | 447b42e608d31fd1cec1%7c72f988bf86f141af91ab2d7cd011db47%7c1=veoz > | Ab6M7N9jZaJZ9tgXZ%2fI8jq7U%2b4YM1FcSXvqTcaw%3d > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ghci and unfoldings?
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 <co...@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 <simo...@microsoft.com> > wrote: > >> Or -fexpose-all-unfoldings? >> >> Simon >> >> | -Original Message- >> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of >> | Edward Z. Yang >> | Sent: 18 January 2016 06:37 >> | To: Conal Elliott <co...@conal.net> >> | Cc: Andrew Farmer <afar...@ittc.ku.edu>; ghc-devs@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 >> | <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
Re: ghci and unfoldings?
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
Re: ghci and unfoldings?
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
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 <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
Re: ghci and unfoldings?
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
ghci and unfoldings?
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? Thanks, - Conal ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ghci and unfoldings?
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, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
