On 16/09/2008, at 19:34, Simon Peyton-Jones wrote:
Interesting idea Neil. Roman: I think you only need deep
specialisation on non-recursive constructors, don't you?
Yes, as long as the definition of recursive doesn't include things like
data T a where
Pair :: T a -> T b -> T (a,b)
...
and similar constructs for indexed types. I'm not really convinced
about this idea, though. What is so special about recursive
constructors? And why is generating all specialisations in this
particular case bad at all? In the end, all but the one for
dropComment (x:xs) are eliminated which roughly doubles the code size.
There are a couple more tiny leftovers but that's only because GHC
isn't even trying to get rid of them. To be honest, I don't quite see
the problem here.
In fact, in this example SpecConstr actually performs a fairly complex
optimisation which, unfortunately, doesn't bring much (I think;
benchmarking the lexer with and without SpecConstr would be useful).
dropComment (' ':'-':'-':' ':_) = []
dropComment (x:xs) = x : dropComment xs
dropComment [] = []
Without SpecConstr, we have:
dropComment (' ':'-':'a':...)
-> dropComment ('-':'a':...)
-> dropComment ('a':...)
SpecConstr skips the second step (i.e., saves a recursive call)
because it knows that the argument won't match the first equation. For
Haddock, this isn't a big win unless the input file contains a lot of
space/dash sequences. However, I can easily imagine programs where
this optimisation would be very desirable.
Roman
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
