Turning ForceSpecConstr/NoSpecConstr into pragmas?

[Johan Tibell]

This insight is this: in stream fusion what we're trying to SpecConstr
away is the intermediate stream state constructor, so why not just say
that, instead of annotating every function. By annotation the Stream
constructor we're more explicit in what we want to happen. In fact, we
could even have GHC omit a warning if it couldn't eliminate the
constructor!

On Wed, Oct 9, 2013 at 8:03 AM, Andrew Farmer <afarmer at ittc.ku.edu> wrote:
> Wouldn't #2 mean we'd have to annotate (via pragma) every type we want to
> eliminate, rather than a single type?
>
> I think the current design serves the need: "I want you to try really hard
> on this function." ... which seems useful.
>
> #2 seems like an orthogonal issue: "I want to ensure this type is optimized
> away" ... which also seems useful, but I'm not sure it replaces the first
> use. (Though I missed the suggestion at ICFP... is this the ephemeral types
> one?)
>
>
> On Wed, Oct 9, 2013 at 9:55 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>
>> On Wed, Oct 9, 2013 at 7:13 AM, Austin Seipp <austin at well-typed.com>
>> wrote:
>> > Early last week I was reminded of something, which was that vector/dph
>> > depend on the stage2 compiler - this is because both packages use
>> > annotations to specify ForceSpecConstr and NoSpecConstr on several key
>> > datatypes.
>> >
>> > For most of our platforms (now including ARM,) this should generally
>> > be OK, because we have stage2 and the linker available to support it.
>> >
>> > But in particular, it makes vector and dph unusable for cross
>> > compilers. This might be somewhat problematic for e.g. iOS or an RPi,
>> > where we only have a stage1 cross compiler - but it's reasonable to
>> > assume we may want to use vector there! And more and more libraries
>> > depend on vector these days.
>>
>> I raised the same issue with Simon PJ a while ago. We ran into this
>> problem when trying use GHC as a cross-compiler at Google. I think we
>> should
>>
>>  1. Convert it to a pragma.
>>  2. Look into a design that was suggested at ICFP, namely to put a
>> pragma on the data type we want to get optimized away instead.
>>
>> -- Johan
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>