| It looks like List.partition
| is a stack eater in GHC-4.04.
| And this can be improved easily.
| Probably, there are many other stack or heap eaters.
| What the implementors think of this?
As various people have said, one can turn non-tail-recursive functions
into tail-recursive ones, using an accumulating parameter.
But this isn't obviously a win. Stack usage is decreased, but heap
usage is increased by the same amount. It's not clear to me that
the former is better than the latter (GHC, at least, grows its stack
dynamically, and Hugs will too once we've completed the GHC/Hugs
integration).
I'm not sure how partition could be made much more efficient
without also making it stricter.
In general, though, we have not devoted a great deal of effort
to performance-tuning the GHC prelude. If anyone finds a definition
of a prelude function that out-performs the one that comes with
GHC, please send it and we'll plug it in.
Simon
