can a lazy language give fast code?
Manuel M T Chakravarty
chak@cse.unsw.edu.au
Wed, 31 Jul 2002 11:53:06 +1000 (EST)
Andrew J Bromage <ajb@spamcop.net> wrote,
> On Tue, Jul 30, 2002 at 01:57:58PM +0200, Josef Svenningsson wrote:
>
> > I think the reason why Haskell compilers aren't generating any faster code
> > is that there is a lack of competition among different compilers. And I
> > think that the lack of competition depends on that noone wants to write a
> > front-end to Haskell.
>
> There's no competition in Haskell compilers because there is no
> money in it. It might not even be "boring work" in most cases.
> The reality is that if there's no research quota or postgraduate
> degree to be gained, nobody will fund a university or other research
> institution to actually do the work.
I think the situation is more complex than this. First of
all, there are three Haskell compilers (admittedly one of
them isn't supported anymore). Secondly, there are at least
three projects working at new Haskell compilers (of one, I
am not sure whether it is still going) - this doesn't
contradicting your point, though, as all three are
research-oriented projects.
Moreover, if you look at the available open source C
compilers, then the situation is not that different. There
is gcc, then a big gap, and then the rest. Incidentally,
gcc has often been criticised for being difficult to
build/port, being slow, and generating non-optimal code
(sounds familar, doesn't it).
Maybe the "market" (in the OSS sense) just doesn't have a
very high demand for a lean and fast Haskell compiler. In
other words, if you have a choice, would you take a fast
compiler with no libraries or a fast enough compiler with
plenty of libraries? (I think, that fits very well with
your own argument about most applications having spare
cycles.)
Finally, there is a tendency of alternative OSS projects
specialising in different areas (eg, nhc is extremely
portable and focuses on debugging infrastructure).
Cheers,
Manuel