defunctionalization

[Carter Schonwald]

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 <xichekolas at gmail.com> 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" <carter.schonwald at gmail.com>
> 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 <nicolas.frisby at gmail.com
>> > 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 <
>>> simonpj at microsoft.com> 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:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
>>>> Frisby
>>>> *Sent:* 16 July 2013 21:29
>>>> *To:* ghc-devs at haskell.org
>>>> *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" <nicolas.frisby at gmail.com>
>>>> 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
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130719/439879c6/attachment.htm>