Specializing expressions beyond names?
Conal Elliott
conal at conal.net
Mon Feb 1 01:16:24 UTC 2016
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 <conal at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160131/0839b50b/attachment-0001.html>
More information about the ghc-devs
mailing list