I've started a Trac ticket so that we don't lose this thread:
http://hackage.haskell.org/trac/ghc/ticket/2598
I've transferred your comments there and added you to the cc list.
Others: if you are interested, add yourselves.
Simon
| -----Original Message-----
| From: Roman Leshchinskiy [mailto:[EMAIL PROTECTED]
| Sent: 17 September 2008 04:51
| To: Simon Peyton-Jones
| Cc: Mitchell, Neil; [email protected]
| Subject: Re: too many specialisations for one function
|
| 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
