Re: Turning ForceSpecConstr/NoSpecConstr into pragmas?

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 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 wrote:

...

On Wed, Oct 9, 2013 at 7:13 AM, Austin Seipp 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs