Re: evaluation fault in ghci.

Oddity of oddities....

This seems to have nothing to do with the "correctness" of derived Eq, as

let xs = [A,B,C,D,E,ABE,AC,BD,CDE]  in [ map (x ==) xs | x <- xs ]

returns the proper result, though replacing the derived Eq with a handwritten 
version also fixes the problem.

I did happen to discover that simply changing the return result of bceFour to 
depend on tgtF and srcF in the guard fixes the problem.   For example, 
changing the string "it works" to (tgtF == srcF).  It doesn't seem to matter 
for the function applications.

You can change srcF and tgtF to be "srcFour f" and "tgtFour f" in the guard 
and there doesn't seem to be any way of fixing the result as above. 

Almost like the derived Eq is comparing thunks without evaluating them first, 
but why would having "tgtF" and "srcF" on the RHS of the function definition 
change this?  And why would having the LHS of (==) evaluated then force the 
RHS to be evaluated?  

best,
leon


On Thursday 23 January 2003 11:01, Malcolm Wallace wrote:
> The interactive loop of ghci displays an interesting evaluation fault
> to do with derived equality.  In the attached source file, there is
> a simple guard which tests some equalities, and basically the same
> value is given on the left and right of the (==).  Yet, it evaluates
> to False in interactive mode, whereas it (correctly) evaluates to True
> when compiled.
>
>
> $ ghci
>    ___         ___ _
>   / _ \ /\  /\/ __(_)
>  / /_\// /_/ / /  | |      GHC Interactive, version 5.04.2, for Haskell 98.
> / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
> \____/\/ /_/\____/|_|      Type :? for help.
>
> Loading package base ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Prelude> :l Small
> Compiling Main             ( Small.hs, interpreted )
> Ok, modules loaded: Main.
> *Main> main
> "*** Exception: Four.bceFour: precondition fails:arrows not parallel
> f = E
> g = E
>
>
> $ ghc -o Small Small.hs
> $ ./Small
> "it works"
>
>
> I have verified that the fault exists at least as far back as 5.02.3.
>
> Regards,
>     Malcolm