
On Thu, Oct 10, 2013 at 2:46 AM, Manuel M T Chakravarty < chak@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
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
Simon Peyton-Jones
: 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@haskell.org] On Behalf Of
| M T Chakravarty | Sent: 10 October 2013 04:03 | To: Austin Seipp | Cc: Roman Leshchinskiy; ghc-devs@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
: | > 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 | > 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
Manuel the -
| > 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@haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs