Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#10688 closed bug (invalid)

Incorrect program produced, different result with equivalent code

Reported by: Ideophage Owned by:
Priority: lowest Milestone:
Component: Compiler Version: 7.10.1
Keywords: Cc:
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by Ideophage)

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.

Attachments (2)

bug1.hs (1.0 KB) - added by Ideophage 3 years ago.
bug1.2.hs (1.0 KB) - added by Ideophage 3 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by Ideophage

Description: modified (diff)
Priority: normallowest

comment:3 Changed 3 years ago by Ideophage

Description: modified (diff)

comment:4 in reply to:  1 Changed 3 years ago by Ideophage

Replying to 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.

Changed 3 years ago by Ideophage

Attachment: bug1.hs added

Changed 3 years ago by Ideophage

Attachment: bug1.2.hs added

comment:5 Changed 3 years ago by thomie

Resolution: invalid
Status: newclosed

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

comment:6 Changed 3 years ago by 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

comment:7 in reply to:  6 Changed 3 years ago by Ideophage

Replying to 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.

comment:8 Changed 3 years ago by rwbarton

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

Note: See TracTickets for help on using tickets.