I’m sorry Conal I’m not getting this. Specialisation happens when you have a named chunk of code that is repeatedly called at different types, and with different args. We can inline it bodily to specialise to that one call site, but it’s cooler to make a single specialised version which can be shared among many call sites. (And that approach deals with recursive functions too.)
But that explanation is fundamentally about named functions, so I don’t understand this “general expression” bit. Sorry! Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 01 February 2016 01:16 To: ghc-devs@haskell.org Subject: Re: Specializing expressions beyond names? A related question: if there are a great many rules of the form "reify (foo ...) = ...", where 'reify' is always present (and the outermost application head) but for many different argument expressions, will rule matching be linear (expensive) in the number of such rules? -- Conal On Sun, Jan 31, 2016 at 1:58 PM, Conal Elliott <co...@conal.net<mailto:co...@conal.net>> wrote: It seems to be the case that SPECIALIZE pragmas are syntactically restricted to type specializations of a name (identifier) rather than a general expression. Is my understanding correct here? If so, is there any reason for this restriction? I ask because I’m reifying Core code (into code that constructs a corresponding run-time representation for further processing), and I’m looking for a clean way to integrate that process with GHC, to support separate compilation and to avoid interfering with GHC’s regular flow. It occurred to me that I could enable separate compilation via a pragma of the form “{-# SPECIALIZE reify foo ∷ E t #-}” for some t, where E t is a reified form of values of type t. Type checking would infer the specialized type of foo, and the usual specialization phase would do its usual thing on that specialization, leaving “reify foo = reify specialized_foo”, and then the reification compiler plugin would transform the right-hand side, pushing the reify inward. Some reify calls may remain (e.g., due to polymorphism), triggering future rule applications. As much as possible of the fully-reified version would be factored out of the generated rule’s RHS for cheap reuse. Thanks, - Conal
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
