Hi Adrian,
| Ah, now I see the issue seems to be closeley related to
| full lazy lambda lifting.
That's right ...
| Do (should) Haskell compilers do this, as a general rule?
| It all seems bit vague to me :-(
I don't think they do, and I'm not sure they should
because the transformation can,
On Thu, 10 Jan 2002, Mark P Jones wrote:
| If I have defined a function like this..
| f args = blah args
| it could be re-written..
| f = blah
[snip]
- The second will compute a value of blah at most
once, then cache the result for future use. That
could make a program run
On Friday 11 January 2002 8:46 am, D. Tweed wrote:
Even sillier question: there's no other way of getting the optimization
that normCorr' has over normCorr (as always on the understanding it may
be a space leak) in Haskell?
dotProd xs ys=sum(zipWith (*) xs ys)
normCorr :: Floating a = [a]
Thanks Mark,
On Friday 11 January 2002 7:41 am, Mark P Jones wrote:
Denotationally, the two expressions are the same.
(In other words, they both produce the same value.)
But the example above shows an operational difference
in some implementation. (As far as I can tell, however,
Hello,
Here's something I've always wanted to know but
have never dared ask until now (it seems so basic).
If I have defined a function like this..
f args = blah args
it could be re-written..
f = blah
I had always assumed the internal representation of
these 2 definitions would
The only semantic difference is in the type checker - the first form
is not subject to monomorphism while the latter is unless a type
signature is present. There should be no difference at all in the
generated code.
John
___
Haskell mailing list
Hi Adrian,
| If I have defined a function like this..
| f args = blah args
| it could be re-written..
| f = blah
|
| I had always assumed the internal representation of
| these 2 definitions would be identical (and should
| yield identical code), but it appears that isn't so
| (with
