## #3053 closed bug (invalid)

# Modular arithmetic bug?

Reported by: | vlaad | Owned by: | |
---|---|---|---|

Priority: | normal | Milestone: | |

Component: | GHCi | Version: | 6.10.1 |

Keywords: | Cc: | ||

Operating System: | Windows | Architecture: | x86 |

Type of failure: | None/Unknown | Test Case: | |

Blocked By: | Blocking: | ||

Related Tickets: | Differential Rev(s): | ||

Wiki Page: |

### Description

GHC dies here (please note the x < 200 limit):

take 15 [x | x <- [1..], x < 200, x

`mod`

6 == 1, x`mod`

6 == 5]

And here (nothing with infix notation):

take 15 [x | x <- [1..], x < 200, mod x 6 == 1, mod x 6 == 5]

But *not* here:

take 15 [x | x <- [1..], mod x 6 == 1, x < 200, x > 100]

### Change History (9)

### comment:1 follow-up: 4 Changed 11 years ago by

### comment:2 Changed 11 years ago by

Component: | Compiler → GHCi |
---|

### comment:3 Changed 11 years ago by

Resolution: | → invalid |
---|---|

Status: | new → closed |

### comment:4 Changed 11 years ago by

Resolution: | invalid |
---|---|

Status: | closed → reopened |

Otherwise, GHC will happily try and dismiss all those numbers in

`[200..]`

, which will keep it busy for a while!-)

Why then we forget about infinite series support, if we have to wait the GHCi to approach the infinity?

Here is another one NOT WORKING: take 2 [x | x <- [1,2..], x < 195, x > 188, mod x 6 == 2]

Please don't tell me that GHCi will enumerate from 1 to infinity, what about this WORKING example:

take 2 [x | x <- [255255..], mod x 15 == 2]

### comment:5 Changed 11 years ago by

Resolution: | → invalid |
---|---|

Status: | reopened → closed |

Both ghc and ghci are working exactly as they should. If you say

[ x | x <- [1..], x < 10]

then it will let x go through all the numbers from 1 and up, and only keep those that are < 10. The compiler "does not know" that the seqeunce is monotonically increasing, so it has to loop after delivering 9, because it "thinks" that somewhere in the infinite list (beyond 9) there could again be a number < 10.

This is **not** a bug.

(And indeed, for some non-standard kind of numbers it could very well be that enumFrom would deliver some smaller numbers later.)

### comment:6 follow-up: 7 Changed 11 years ago by

Well, if this is *not* a bug, then please explain how in your first response we are getting an empty list? (or better, stop thinking, and pass it to the guys, please).

("Perhaps you mean [x|x<-[1..200],x`mod`

6==1,x`mod`

6==5]")

Prelude> [x|x<-[1..20],x`mod`6==5] [5,11,17] Prelude> [x|x<-[1..20],x`mod`6==1] [1,7,13,19] Prelude> [x|x<-[1..20],x`mod`6==1,x`mod`6==5] []

### comment:8 Changed 11 years ago by

However, I'm totally dicouraged in using GHC, thanks to the fact that it is the only Haskell compiler around, and thanks to your fanatic dedication to it's advocacy (I've just happily uninstalled it).

### comment:9 Changed 11 years ago by

Why are you discouraged by ghc? What you reported is not a bug and all Haskell implementations will give you the same answer.

To put it another way, of you have a list comprehension [ e | x <- gen, ... ] and you look at the resulting list then the result list will only ever end when the generator (gen) gets to the end of its list. This is according to the definition of Haskell and has nothing to do with ghc.

If you want a language where list comprehensions behave in some other way, then you'll have to look elsewhere.

**Note:**See TracTickets for help on using tickets.

The

`x<200`

is a *filter*, not a limit. Perhaps you meanOtherwise, GHC will happily try and dismiss all those numbers in

`[200..]`

, which will keep it busy for a while!-)