
Max,
If you want to look at a simple example, look at the Inf.hs example
included in the package.
It's very simple, and ghc generates fantastically bad code for it.
It would be great if you could nail down why it's so amazingly unoptimal.
Even with everything inlined and no overloading left, ghc seems to
ignore the INLINE directives and use dictionaries left and right.
-- Lennart
On Mon, Mar 30, 2009 at 11:20 PM, Max Bolingbroke
2009/3/30 Don Stewart
: Duncan and I have thought about this too, exactly as you describe.
(Just !x) => (# tag#, x# #)
It would be nice to generalize this to arbitrary sum types, but doing so plays hell with the type checker - I think the most straightforward way would be to extend Core with a type-level case statement on tag values similar to \Pi\Sigma.
BTW you can manually apply the worker/wrapper transform to arrayU to realise this optimisation in todays GHC. However, I couldn't get GHC to inline the definitions of (-) etc from Ops though - seems to be an issue with it throwing away INLINE annotations on the appropriate dictionary members of Num.
If both of these things were fixed you would /still/ get bad code, because mapM (used in arrayU) does not produce a fusible list, so the resulting program still builds the lists that masquerade as array indexes and then folds over them. Disappointing, but this can also be solved, as long as you apply the monadic stream technology from Roman's vector package.
Apologies for the brevity of these notes, but perhaps they make some of the issues clearer. GHC really should be doing much better here :-(
Cheers, Max