Turning ForceSpecConstr/NoSpecConstr into pragmas?

Thu Oct 10 16:51:28 UTC 2013

(Blagh, sorry for the double-email to those involved. I forgot to use
my email for this list. Verbatim response below.)

-------

Hi all,

It seems there seems to be some consensus about making some changes to
ForceSpecConstr. Indeed, cross compilation of vector is, I think, a
Big Deal, and as people begin deploying cross compilers more, this
will probably become more of an issue - according to
http://packdeps.haskellers.com/reverse/vector it has almost 400
reverse dependencies! And this includes some packages - like aeson,
io-streams, mwc-random, statistics - that are quite a big deal to a
lot of people.

I understand that ForceSpecConstr is a bit of a hack (and I, of
course, don't know how to fix it either :) And note that I was
intentionally conservative in my original proposal to not introduce a
lot more stuff or really shift things around - preferably, this would
be easily doable in the 7.8 timeframe with minimal changes to vector
itself.

So all that said, let's take DPH and NoSpecConstr out of the picture for now.

After thinking about it more, rather than threading a pragma
throughout the compiler, I'm coming around to the point Andrew brought
up at first - make SPEC something of a built-in library type (perhaps
exported from ghc-prim,) which the SpecConstr pass deals with
specifically. This is close to what we do now, we just look at the
ForceSpecConstr data type instead in the SpecConstr pass. So, this
means

A) we don't add any new syntax, just a new wired-in for SPEC, which
might require a little fiddling.

B) Vector can be upgraded with minimal changes (and #ifdef'd
appropriately for older compilers, since they don't really support
cross compilation that well.)

Does this sound acceptable to those interested? If there aren't any
complaints I can file a ticket pertaining to this.

On Thu, Oct 10, 2013 at 9:16 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Thu, Oct 10, 2013 at 2:46 AM, Manuel M T Chakravarty
> <chak at cse.unsw.edu.au> wrote:
>>
>> It's also used by vector, which is widely deployed and, I think, doesn't
>> use TH otherwise.
>
>
> Not bring able to compile vector with a cross compiler is the problem we
> had.
>
>>
>>
>> Manuel
>>
>>
>> Simon Peyton-Jones <simonpj at microsoft.com>:
>> > It's true that I suggested making it an annotation.  The DPH libraries
>> > use a lot of Template Haskell and so have to be compiled with a stage2
>> > compiler anyway.
>> >
>> > The thing about ForceSpecConstr is that it is an unprincipled hack that
>> > I hate with a passion. It clearly is not the Right Thing. I just don't yet
>> > know a better way to do it.  Johan suggests a more principled approach,
>> > about eliminating uses of the stream constructor. I know that Roman
>> > considered that but could not make it work.  I'm afraid I can't remember
>> > why.
>> >
>> > Because it is such a hack I'm reluctant to bake it more deeply into the
>> > compiler, and to sink further effort into doing so.  Also I'm not sure what
>> > problem we are trying to solve here. If it's compiling DPH libraries with
>> > stage1, that won't work because they use TH.
>> >
>> > All that said, I don't seriously object to someone making it a pragma if
>> > you want.   Just make clear that it's a horrible hack.
>> >
>> > Simon
>> >
>> >
>> > | -----Original Message-----
>> > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> > Manuel
>> > | M T Chakravarty
>> > | Sent: 10 October 2013 04:03
>> > | To: Austin Seipp
>> > | Cc: Roman Leshchinskiy; ghc-devs at haskell.org
>> > | Subject: Re: Turning ForceSpecConstr/NoSpecConstr into pragmas?
>> > |
>> > | This feature was implemented as an annotation by Roman in part because
>> > | Simon was keen to see the then new annotation feature used, in part
>> > | because we were unsure whether the design would last, and it part as
>> > it
>> > | seemed easier than hacking it into GHC.
>> > |
>> > | Personally, I would have always preferred it to be a proper pragma,
>> > | mainly for the reason that causes grief now (i.e., because it requires
>> > | stage2). So, as far as I'm concerned, please make it a pragma.
>> > |
>> > | Manuel
>> > |
>> > | Austin Seipp <austin at well-typed.com>:
>> > | > 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/
>> > | > _______________________________________________
>> > | > 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
>> > _______________________________________________
>> > 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
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

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