On Thu, Oct 10, 2013 at 2:46 AM, Manuel M T Chakravarty < [email protected]> 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 <[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 >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
