When I launch
ghci> last [0..]
I can interrupt it with Ctrl+C.
However
ghci> last (repeat 0)
cannot be aborted with Ctrl+C. GHCI silently ignores the keystrokes.
How to abort this command in GHCI? Is it a bug?
(Caveat lector: I use Linux, and run zsh on urxvt or gnome-terminal. If you use a different operating system, terminal, or shell, it's possible this will work differently for you.)
The way I usually handle this is to hit Ctrl+Z (which puts it in the background, pausing execution entirely as a side-effect) then kill the job. Usually this is kill %1, though you can run jobs to double-check.
You can also start a new terminal and do something like killall -9 ghci, but this has a much higher resource cost: you are spawning a few new processes, opening X connections, doing whatever it is your terminal does when it initializes itself, doing whatever it is your shell does when it initializes itself, etc. If you're in the situation I often find myself in -- ghci is swapping like crazy -- that just gives ghci more time to screw things up.
If you can predict this problem, and are compiling, you can use -fno-omit-yields to ask GHC to insert Ctrl+C checks even inside tight, non-allocating loops.