1) You can define new functions (and values, and types, type classes, instances, etc). You can "redefine" these things only insofar as you can shadow them.
2) I'm not sure whether they mean the ability to persist your state to disk and restore it (which GHCi lacks), the ability to refer to previous results (in GHCi, the previous result is called `it`), or just the ability to bind variables (of course you can do this in GHCi).
3) Usually "Show" instances are meant to be embeddable in code. Sometimes they need a little massaging. Sometimes they're just broken, from this POV. Sometimes they're just broken, period. But it holds for a lot of values.
4) You can run GHCi in the context of your project (see cabal repl and stack repl commands).
5) GHCi very much fails at this - no way to add anything to a module, so far as I'm aware.
6) GHCi more-or-less lacks this kind of functionality. You could run your server's "main" function from the REPL, but there's not much you can do to it.
7) :reload
8) There's an increasing amount of such tooling; only some of it has any particular tie to the REPL, per se.
Yes for (3)! I just plainly hate data types whose Show instances aren't just Haskell syntax. They usually try to add some pretty printing but that just ends such hurting copy-pasting from the REPL to the editor.
I'm curious what makes this superior to Beanshell. Or any other style of REPL that you could do on the JVM.
Not against the idea, per se, but it seems hardly new ground. And unlikely to be nearly as powerful as a REPL in CL. (Though, again, few things are. Not sure that any are, to be honest.)
My question in that vein is more of "why will this succeed, where beanshell failed?"
That is, I had REPL style environments for java a long time ago. And literally nobody used it. I can see arguments for having the REPL being in actual Java instead of a shell subset. But, Java has a long way to go from bootstrapping something in a repl and automatically saving it to something that will work as a normal entry point. (Though, again, even JRebel has existed for a long time now.)
I doubt many programmers already using Jython, Beanshell, Apache Groovy, Xtend, Rhino, or Nashorn will change to the Java 9 JShell. I switched from Groovy to Clojure for scripty stuff a few years ago, mainly for the macros. A well-placed macro can avoid a lot of clutter in repetitive testing -- a far better solution than some heavy-weight testing framework.
If you want to be literal about it then sure, it just means read-eval-print loop. But I think that's akin to saying that a functional programming language is a language that has functions in it.
EDIT: To be clear, what I'm saying is that when people say 'I really love using Common Lisp because it has a REPL' they aren't saying 'I really love using Common Lisp because it has a prompt I can write raw strings of code into that executes that code and has no other features'. That's not a lovable feature.
People love Lisp REPLs because there's much more to them than that. In Lisp, the REPL is more like GDB than it is like Python's REPL.
Not really sure why the reaction to my comments here is so viscerally negative. Very few terms that we use are wholly literal. REPL isn't literal either.
Sorry if my comment with the definition of REPL seemed "viscerally negative". I understand that a good REPL has more features that just the bare bones, but you said that programs that read an input, evaluated it, and then printed the result aren't REPLs. You should've said that they aren't good or useful REPLs.
Your argument is the equivalent of saying notepad isn't a text editor because you can't edit multiple lines at once or highlight syntax. Those are features that good text editors have, but it does not mean notepad is not a text editor.
A 'command line interface', for example for bash, does the same. What is the difference to a REPL? Is it just another name for the same concept or are there differences? What do you think?
It is a subtyping relationship. Bash's command line is a (minimalistic) REPL, but not all REPL are like Bash's command line. In most contexts, talking about REPLs is implicitly talking about REPLs that do more than just read, eval and print, however illogical that may sound.
Note that few languages actually define READ in a user-friendly way (since python 2.6 you have the ast package, Bash's "read" returns strings).
1) You can define new functions (and values, and types, type classes, instances, etc). You can "redefine" these things only insofar as you can shadow them.
2) I'm not sure whether they mean the ability to persist your state to disk and restore it (which GHCi lacks), the ability to refer to previous results (in GHCi, the previous result is called `it`), or just the ability to bind variables (of course you can do this in GHCi).
3) Usually "Show" instances are meant to be embeddable in code. Sometimes they need a little massaging. Sometimes they're just broken, from this POV. Sometimes they're just broken, period. But it holds for a lot of values.
4) You can run GHCi in the context of your project (see cabal repl and stack repl commands).
5) GHCi very much fails at this - no way to add anything to a module, so far as I'm aware.
6) GHCi more-or-less lacks this kind of functionality. You could run your server's "main" function from the REPL, but there's not much you can do to it.
7) :reload
8) There's an increasing amount of such tooling; only some of it has any particular tie to the REPL, per se.