[Haskell-cafe] Re: Why can't Haskell be faster?
lennart at augustsson.net
Wed Oct 31 19:45:49 EDT 2007
There are many ways to implement currying. And even with GHC you can get it
to do some work given one argument if you write the function the right way.
I've used this in some code where it was crucial.
But yeah, a code generator at run time is a very cool idea, and one that has
been studied, but not enough.
On 10/31/07, Dan Piponi <dpiponi at gmail.com> wrote:
> On 10/31/07, Neil Mitchell <ndmitchell at gmail.com> wrote:
> > in the long run Haskell should be aiming for equivalence with highly
> > optimised C.
> Really, that's not very ambitious. Haskell should be setting its
> sights higher. :-)
> When I first started reading about Haskell I misunderstood what
> currying was all about. I thought that if you provided one argument to
> a two argument function, say, then it'd do partial evaluation. Very I
> soon I was sorely let down as I discovered that it simply made a
> closure that waits for the second argument to arrive so the reduction
> can be carried out.
> But every day, while coding at work (in C++), I see situations where
> true partial evaluation would give a big performance payoff, and yet
> there are so few languages that natively support it. Of course it
> would require part of the compiler to be present in the runtime. But
> by generating code in inner loops specialised to the data at hand it
> could easily outperform C code in a wide variety of real world code. I
> know there has been some research in this area, and some commercial
> C++ products for partial evaluation have appeared, so I'd love to see
> it in an easy to use Haskell form one day.
> Just dreaming, I know...
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe