[First attempt sent from wrong account.] The real solution, in the general scheme of things, would be to make TH work with cross-compilation. I think, the ghc-iOS folks do have a concrete plan for that (i.e., a cross-compiler needs to generate two binaries, one for the target arch and one for the host arch).
Manuel Manuel M T Chakravarty <[email protected]>: > 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 _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
