RE: Understanding strictness of ghc output

| That contradicts my intution for seq. I would read it as "h is forced | before h is forced", and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong? You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it. Here's what I get when I compile your program (with a suitable definition of AVL). The function $wpoly_addHeight is the worker for addHeight. GHC has worked out that addHeight is strict, and has unboxed the first argument, so that it is now of type Int#, as you can see. The DmdType for the Int# is indeed "L" but that's irrelevant because Int# values are always evaluated. The demand info is always L for an unboxed type. Simon Rec { Foo.$wpoly_addHeight :: forall e. GHC.Prim.Int# -> Foo.AVL e -> GHC.Prim.Int# [GlobalId] Arity 2 NoCafRefs Str: DmdType LS Foo.$wpoly_addHeight = \ @ e ww :: GHC.Prim.Int# w :: Foo.AVL e -> case w of wild { Foo.P ds ds1 r -> Foo.$wpoly_addHeight @ e (GHC.Prim.+# ww 2) r; Foo.Z l ds ds1 -> Foo.$wpoly_addHeight @ e (GHC.Prim.+# ww 1) l; Foo.N l ds ds1 -> Foo.$wpoly_addHeight @ e (GHC.Prim.+# ww 2) l; Foo.E -> ww } end Rec } Foo.height :: forall e. Foo.AVL e -> GHC.Base.Int [GlobalId] Arity 1 NoCafRefs Str: DmdType Sm Foo.height = \ @ e w :: Foo.AVL e -> case Foo.$wpoly_addHeight @ e 0 w of ww { __DEFAULT -> GHC.Base.I# ww } | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Tomasz Zielonka | Sent: 22 June 2004 14:18 | To: Malcolm Wallace | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Understanding strictness of ghc output | | On Tue, Jun 22, 2004 at 01:52:44PM +0100, Malcolm Wallace wrote: | > | > Same again. Try | > addHeight h E = h `seq` h | > | > which, although it looks bizarre, actually forces the evaluation of h, | > whilst simply returning it does not. | | That contradicts my intution for seq. I would read it as "h is forced | before h is forced", and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong? | | Best regards, | Tom | | -- | .signature: Too many levels of symbolic links | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

"Simon Peyton-Jones"
| That contradicts my intution for seq. I would read it as "h is forced | before h is forced", and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong?
You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it.
Well, it is certainly the case that in a denotational sense the function is strict in h, because if h is bottom, the result is bottom. But my operational understanding is that h is a projection, that is, it is passed from argument to result unmodified. The demand on h comes from the caller of the present function, which may or may not be strict in that result. Thus, the function code itself here does not force the evaluation of h. Regards, Malcolm

On Tue, Jun 22, 2004 at 02:37:38PM +0100, Malcolm Wallace wrote:
"Simon Peyton-Jones"
writes: | That contradicts my intution for seq. I would read it as "h is forced | before h is forced", and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong?
You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it.
Well, it is certainly the case that in a denotational sense the function is strict in h, because if h is bottom, the result is bottom.
But my operational understanding is that h is a projection, that is, it is passed from argument to result unmodified. The demand on h comes from the caller of the present function, which may or may not be strict in that result. Thus, the function code itself here does not force the evaluation of h.
The point is that, because the function is strict, its implementation may force the evaluation of h, if it so chooses. This is up to the compiler, and as Simon pointed out, it actually does force h when compiling with optimization. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page.

On Tue, Jun 22, 2004 at 02:28:21PM +0100, Simon Peyton-Jones wrote:
| That contradicts my intution for seq. I would read it as "h is forced | before h is forced", and I would think that (h `seq` h) is equivalent | to h. | | Were I am wrong?
You're not wrong -- Malcolm is. The function is certainly strict in h, and GHC finds it.
I will only add that I am aware that my wording is imprecise. It's more like "Forcing (a `seq` b) forces a, then forces b, and then returns the value of b, unless a is bottom or b is bottom - in which case it returns bottom". Best regards, Tom -- .signature: Too many levels of symbolic links

On Tuesday 22 Jun 2004 2:28 pm, Simon Peyton-Jones wrote:
The DmdType for the Int# is indeed "L" but that's irrelevant because Int# values are always evaluated. The demand info is always L for an unboxed type.
Thanks, I had noticed it did appear to have decided h was unboxed (assuming my interpretation of core was correct), so it seemed rather strange that addHeight could be lazy (non-strict) in that argument. So does L mean "Lazy", or something else? Thanks -- Adrian Hey
participants (5)
-
Adrian Hey
-
Carsten Schultz
-
Malcolm Wallace
-
Simon Peyton-Jones
-
Tomasz Zielonka