Turning ForceSpecConstr/NoSpecConstr into pragmas?

Thu Oct 10 23:25:50 UTC 2013

[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 <chak at cse.unsw.edu.au>:

> It's also used by vector, which is widely deployed and, I think, doesn't use TH otherwise.
> 
> 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