Turning ForceSpecConstr/NoSpecConstr into pragmas?

[Austin Seipp]

Hello all,

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 believe these are the only instances in which vector/dph needs
stage2. So I ask: is it reasonable to change this to a pragma built
into the compiler? That is,

------------------------------------------------------------
data SPEC = SPEC | SPEC2
{-# ANN type SPEC ForceSpecConstr #-}

data PArray a
        = PArray Int# (PData  a)
{-# ANN type PArray NoSpecConstr #-}
-------------------------------------------------------------

becomes something like:

-------------------------------------------------------------
data SPEC = SPEC | SPEC2
{-# SPECIALIZE Constructor SPEC #-}

data PArray a
        = PArray Int# (PData  a)
{-# NOSPECIALIZE Constructor PArray #-}
-------------------------------------------------------------

I'm not particularly interested in a bikeshedding discussion about the
exact syntax for the pragma (although this somewhat falls in line with
'INLINE ConLike' as a special case,) - I just want to know if this
sounds reasonable.

Looking at SpecConstr in the compiler, there seems to be quite a lot
of note summarising that we need a better design - in particular,
notes about nuking NoSpecConstr (as it appeared before
ForceSpecConstr,) and turning ForceSpecConstr into a library type of
some sort. I don't propose changing any of this really, just removing
the dependency on the annotations.

But if someone thinks a library type would be better suited for this -
I'm totally fine with that too and am all-ears for a suggestion.

And of course, both of these can continue to be supported for a while,
although the patches to vector, at least, would be trivial to switch
it over.

Ben, Manuel, Simon - you three are the experts here I believe.
Thoughts? Perhaps I'm missing something key here?

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/