## #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 9 years ago by

### comment:2 Changed 9 years ago by

Component: | Compiler → GHCi |
---|

### comment:3 Changed 9 years ago by

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

Status: | new → closed |

### comment:4 Changed 9 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 9 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 9 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 9 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 9 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!-)