SpecConstr and GADTs

[Simon Peyton-Jones]

Some quick thoughts

*         SpecConstr is careful not to generate specialisations that already exist, so it should be ok to run it more than once.

*         SpecConstr can generate a LOT of code, so I'm looking for a way to make it a bit more selective.  The "phantom-type" idea is one such.

Maybe you want to open a ticket, if (a) you become convinced it's important and (b) you can give a concrete example or two.

Simon

From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Nicolas Frisby
Sent: 11 December 2012 00:35
To: glasgow-haskell-users
Subject: SpecConstr and GADTs

I suspect I've found a situation where, to a first approximation, I'd like SpecConstr to run more than once.

I'm specializing on GADT constructors that contain coercions, so the constructor-specialized functions have RHSs with refined types. In my situation, those refined types enable simplifications/specializations that eventually result in additional calls that would lead to further constructor-specializations if the eventual calls were somehow already manifest. But it seems that the simplification/specialization only happens after the SpecConstr pass, so the resulting usages don't lead to further constructor-specialized functions.

Ticket 2642 http://hackage.haskell.org/trac/ghc/ticket/2642 is the only mention I've seen of the SpecConstr pass being repeated.

The more I think about my desired behavior of SpecConstr, the more I suspect that a failure to maximally share the constructor-specializations (leading to possible non-termination) might be a concern if the pass were simply repeated in my particular case.

Regarding broader impact, I suspect this situation might arise with heavy uses of single types.

Is there any known mechanisms to handle this interaction between SpecConstr and GADTs? I'll be able to provide concrete details about my situation in a few weeks, if anyone is interested.

Thanks for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20121219/54cb3e88/attachment.htm>