Incorrect program produced, different result with equivalent code

edit : Actually, I realized that this is not a bug. This is due to the lack of type signatures in my program. I thought that was a bug because sometimes the program used Ints, sometimes Integers, and just expanding a definition can change this (see the code in attachment). I apologize for opening a ticket for that (I thought Integers were used since it is the case in ghci).

Below my original message.

The program enters an infinite loop (100% cpu, not stopping) because it fails to recognize the stopping condition of a takeWhile. If we make the list finite, it takes all the elements while it should stop before.

I don't know how to simplify the code since if I change it a little (e.g. by replacing the name of an object by its definition), sometimes it works well, sometimes not.

When I enter the code in ghci, it works well but not when compiled.

I don't know if I should explain what the code was for initially, tell me.

changed weight to 5

added Tbug Trac import labels

Is it possible to upload a (presumably large) program which reproduces the problem? Even some code snippets would help; what's the stopping condition of takeWhile? Can you reproduce with -O0? Can you try with 7.10.2 or even the latest master version of GHC? Some description of what the code does would also be useful.

changed weight to 0

Trac metadata

Trac field	Value
Priority	normal → lowest

changed the description

Replying to [ticket:10688#comment:102791 ezyang]:

Is it possible to upload a (presumably large) program which reproduces the problem? Even some code snippets would help; what's the stopping condition of takeWhile? Can you reproduce with -O0? Can you try with 7.10.2 or even the latest master version of GHC? Some description of what the code does would also be useful.

Thanks for your reply. I checked the box for adding an attachment and I thought my ticket was not opened. I added the code. This is reproducible with -O0.

Attached file bug1.hs ($1115).

Attached file bug1.2.hs ($1116).

closed

edit : Actually, I realized that this is not a bug.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

Interesting. Now that you understand what went wrong, you could write a note explaining the trap you fell into, and share it with others. It is, after all, rather surprising when you are told "omit a type signature and you get an infinite loop".

Simon

Replying to [ticket:10688#comment:102857 simonpj]:

Interesting. Now that you understand what went wrong, you could write a note explaining the trap you fell into, and share it with others. It is, after all, rather surprising when you are told "omit a type signature and you get an infinite loop".

Simon

I don't know if it's always the case, but according to my tests, the type inferrence algorithm specialize the types without class constraints (however, if we enter :t (unlines . map show) in GHCi, the polymorphic type is inferred). For instance, the following code either prints "1" or generates an error depending on whether we comment out or not the definition of print_b (which is not used) :

a = (2^64) `div` (2^64) -- 64 or 32
b = length []

show' = show

print_a = print $ show' a
-- print_b = print $ show' b

main = print_a

This is because if we apply show' to b, then the inferred type of show' becomes Int → String (I expected it to be the same as show) and because we also apply it to a, the inferred type of a becomes Int. The « types implication graph » of the code I first gave was more complex, but there is nothing more than this involved.

I thought it was a bug because I assumed GHC's Haskell was referentially transparent even without explicit types annotations (so that expanding a definition, adding a definition, etc. was not supposed to make a program do something else), but I don't know what is feasible.

The infinite loop is due to the fact that the termination rely on arithmetic properties of Integer.

Right, it's not a bug, but it is a confusing consequence of the monomorphism restriction together with defaulting and type inference.

added incorrect runtime result label

added Plow label