naively, it might really blow up compilation times perhaps? (i'm speculating on the compilation time possibility) Large haskell projects do take a while to build as is, so any changes that can blow up compilation times really merit being thoughtful.
On Thu, Jul 18, 2013 at 6:20 PM, Andrew Farmer <[email protected]> wrote: > Maybe this is a good time to ask, since I've always been curious... is > there a reason -fexpose-all-unfoldings is not the default? > > That is, is there a strong reason to not include the original RHS of > *every* exported function in the interface file, regardless of its > INLINE/NOINLINE status? This would greatly benefit HERMIT users, for > example... or other plugins that do some form of partial evaluation. > > I realize interface files would be bigger, but disk is cheap. They would > also change more often, maybe triggering more recompilation? Thoughts? > > Drew > On Jul 18, 2013 3:10 PM, "Carter Schonwald" <[email protected]> > wrote: > >> So the idea here to make it possible to have a function that can be >> specialized at certain types, and explicitly inlined at specific use >> sites, but ghc otherwise will not inline it? Cool! >> >> one thought: might it be simpler to instead have something like >> EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas >> which "seem" contradictory? >> >> >> >> On Thu, Jul 18, 2013 at 3:30 PM, Nicolas Frisby <[email protected] >> > wrote: >> >>> This table outlines my plan for the compatibility of the pragmas. >>> >>> Each cell is formatted as "x/y", where "x" answers "Is the original RHS >>> in the interface file?" and "y" answers "Will GHC try to inline it?". >>> >>> NOINLINE INLINABLE INLINE >>> <none> no/no yes/yes yes/enthusiastically >>> >>> NOINLINE error yes/no error >>> INLINABLE - error error >>> INLINE - - error >>> >>> The proposed new "yes/no" option gives the GHC user more control. It >>> prevents GHC from inlining a function while still supporting the ability to >>> use the annotated function's RHS in another module, via SPECIALISE or the >>> special "inline" function. Moreover, the presence of the RHS in the .hi >>> file could be used by tools other than GHC like plugins or a super-compiler. >>> >>> >>> On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones < >>> [email protected]> wrote: >>> >>>> It seems a little weird, but the internal data types can express it, >>>> so if you can make the front end do the right thing I’d be happy to take >>>> it. (Don’t forget the manual.)**** >>>> >>>> ** ** >>>> >>>> SImon**** >>>> >>>> ** ** >>>> >>>> *From:* ghc-devs [mailto:[email protected]] *On Behalf Of >>>> *Nicolas >>>> Frisby >>>> *Sent:* 16 July 2013 21:29 >>>> *To:* [email protected] >>>> *Subject:* Re: defunctionalization**** >>>> >>>> ** ** >>>> >>>> Ah, I misread that TidyPgm function.It looks like if I build the >>>> CoreUnfolding, GHC will respect it. It's just rejecting the pragma >>>> combination in HsSyn.**** >>>> >>>> On Jul 16, 2013 3:22 PM, "Nicolas Frisby" <[email protected]> >>>> wrote: >>>> > >>>> > I'd like to put a NOINLINE and an INLINABLE pragma on a binding. >>>> > >>>> > (I'm sketching a defunctionalization pass. I'd like the 'apply` >>>> routine RHS to make it into the interface file, but I do not want it to be >>>> inlined, since that'd undo the defunctionalization.) >>>> > >>>> > In other words, I'd like a CoreUnfolding value with the uf_guidance = >>>> UnfNever. >>>> > >>>> > It seems TidyPgm.addExternal ignores such a core unfolding. >>>> > >>>> > Would GHC consider a patch to make this work? >>>> > >>>> > Thanks.**** >>>> >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
