Turning ForceSpecConstr/NoSpecConstr into pragmas?

Thu Oct 10 14:16:40 UTC 2013

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131010/4a3066e9/attachment.html>