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, i
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,
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
On Thu, 10 Jan 2002, Mark P Jones wrote:
> | If I have defined a function like this..
> | f =
> | it could be re-written..
> | f =
[snip]
> - The second will compute a value of at most
> once, then cache the result for future use. That
> could make a program run faster, but if t
Hi Adrian,
| If I have defined a function like this..
| f =
| it could be re-written..
| f =
|
| 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 ghc at least). S
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
[EM
