Comment by anon_d
12 years ago
Meh. You want to do imperative stuff in the repl, and you can't do that at the top-level in Haskell. The way ghci works is solid. When you are in the ghci repl, you are coding inside the do-notation for the IO monad.
Really, IMHO, jumping back and forth between the editor and the REPL with constant reloading is a better approach than pasting things into the REPL. I remember when I was playing with Common Lisp, I would always have trouble keeping the code on disk and the code loaded into the REPL synced.
>I remember when I was playing with Common Lisp, I would always have trouble keeping the code on disk and the code loaded into the REPL synced.
Then you're doing it wrong. Most people doesn't type directly into the REPL, they open up a separate buffer in Emacs and play in that. The REPL is just for small tests. There is no such thing as 'keeping the code synced'.
I don't know how you develop Lisp, but one style which seems encouraged by environments like SLIME is this: You write your file in emacs, and each time you finish a function definition you hit the "send definition to repl" keystroke, and then experiment a bit in the repl to see that you got it right.
If you do things this way, the state of the running lisp interpreter depends on the entire history of the coding session. Each time you add a new definition, you mutate the interpreter's memory. There is no guarantee that the current state matches what you would have if you recompiled the entire system from scratch.
On the other hand, the usual style in Haskell development is that you write a function definition and then hit the "reload" key combination, and this makes the state of the repl exactly the match the contents of the file. It throws away the results of any commands you ran in the repl in the meantime.
(This seems like an interesting cultural difference, something like "Haskell/ML/Java/Scheme programmers think of a program as a text, Common Lisp/Smalltalk programmers think of a program as an OS process").
One does that in Lisp, too. But often we want to avoid that. Lisp programs are often written in such a way that interactive modification is painless. There are a few very large Lisp programs which would take too long to compile/load each time. Thus we learn to deal with changing running programs. A Lisp system is often like a big collection of objects.
That's how I was doing it. It's been too long to remember the details, but I remember that there are different phases when code is loaded, and it can get very tricky when you're doing heavy meta-programming stuff. Everything works when load your new definitions from a buffer into the repl, but when you try to load it again from a file, all the phase issues come into play.
Yes, there is some potential for confusion here. Usually the problems can be solved by appropriate use of EVAL-WHEN.
The main thing I use a REPL for is playing around with defining/redefining functions and then using them in various ways, and the different syntax plus the weird :{ :} business made that tedious in GHCi. So I ditched it and just moved to the old-school C-style "edit a file, save, compile, run" cycle.
I've settled into the following workflow:
It's the best programming work-flow I've found in any language.
With emacs and haskell-mode, I just open a Haskell buffer, and C-c C-l (control-c control-l). This will reload that buffer into another buffer that runs GHCi, creating it if it doesn't exist and using the existing one if it does.