It's also used by vector, which is widely deployed and, I think, doesn't use TH otherwise.
Manuel Simon Peyton-Jones <[email protected]>: > 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:[email protected]] On Behalf Of Manuel > | M T Chakravarty > | Sent: 10 October 2013 04:03 > | To: Austin Seipp > | Cc: Roman Leshchinskiy; [email protected] > | 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 <[email protected]>: > | > 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 > | > [email protected] > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | [email protected] > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
