Although there have been some improvements to the Kotlin REPL (eg can run a JavaFX program using TornadoFX) it still ends up being crippled when looking at other language REPLs (eg Python, JShell). Really frustrating to see the Kotlin REPL improving at what appears to be at a glacial pace, and some major problems/regressions still exist which should have been fixed (eg exiting causes the REPL to freeze in certain situations). Having a crippled REPL hinders Kotlin’s adoption as a language for tool scripting (eg automating Gradle builds), which is a preventable situation that should have been avoided.
The state of the Kotlin REPL is so bad that JShell comes across as significantly more feature complete/stable. Rather astonishing considering JShell doesn’t have a stable release yet… One really has to wonder if far more attention is going to be paid to the Kotlin REPL in Kotlin 1.2. Is tooling one of the key priorities for Kotlin 1.2? These are the core problems that currently exist with the Kotlin REPL:
Many Kotlin languages features are unsupported
Not enough REPL commands provided
Kotlin code isn’t very readable without syntax highlighting
Difficult to distinguish REPL feedback from code
Insufficient REPL documentation (REPL acts like a black box - lots of trial and error)
Too many major REPL stability issues/regressions
Lack of integration with terminal shell
Can’t use code snippets in REPL
REPL doesn’t do concurrency properly (is single threaded), can’t run mutiple things at once
Luckily there is an opportunity to turns things around for the Kotlin REPL (make the best of a bad situation). Would be good to look at key things being done in the Python and JShell REPLs which are missing in the Kotlin REPL. Have some possible suggestions on improving the Kotlin REPL:
Basic coloured syntax highlighting
Lazy loading of Kotlin code snippets on the fly from a file or directory containing snippet files
List all defined Kotlin elements in the REPL session
Show the definition of a existing Kotlin element in a REPL session
Implement support for defining packages
Allow a defined element to be undefined provided it isn’t a dependency
Provide semi visual (coloured) feedback for info, warning, and error messages
Add support for running, switching, and managing multiple REPL environments (using the same Kotlin version) that are isolated
Have basic message passing (communication) between multiple REPL environments without sharing state
Integrate further with terminal shells (eg Bash)
Ensure keyboard input is correctly interpreted (no garbled characters)
Enable Kotlin Coroutines to be used in the REPL without any major restrictions (eg for concurrency, and GUI prototyping)
Provide complete/comprehensive REPL documentation
Allow additional types of software development to be done in the REPL (greater flexibility)
I have to confirm that. My latest experience with Kotlin REPL was so frustrating that I finally stopped using it! I wanted to use it in a presentation, but to avoid blaming myself I decided to put all examples in a main function running it “traditionally”. This is a shame especially since the REPL might be the first thing a newcomer may have contact with.
Apart from support for all language features, I whish there would be
some type information (like in the Scala REPL)
basic syntax “completion” (pressing TAB and see a list with methods available)
All these things are good to have, but kotlin team is not so large so it is probably not reasonable to do everything at once. Many of these feature requests could be implemented by community, but one thing the Kotlin team should do to make it possible is to disentangle REPL itself (meaning evaluation engine) from the shell implementation (like it is done in GroovyShell).
In my opinion, the only important thing the GroovyShell API lacks is some code analysis tools (for autocompletion, highlighting etc.). The parser analyzes code anyway, so why not export some of its functionality as a user friendly API.
@darksnake - Are you suggesting that Kotlin needs an official compiler API (eg like a language server similar to what C# has)? Not sure if it is a hint that the Kotlin team need to make it significantly easier to have Kotlin supported in text editors (eg Sublime Text).
Actually new features are not that important to me, but the REPL should support all language features, it should run mostly without bugs and it should not slow down over time. So, it should basically work without problems what is not the case today. Everything else is nice to have.
First tried the Kotlin REPL in Kotlin 1.0.3 back when I was starting out with Kotlin. Can try the Kotlin REPL in the terminal by installing the Kotlin compiler tools and running the kotlinc (with no program arguments) command. There is even a tiny amount of documentation on the Kotlin REPL. Absolutely certain the Kotlin REPL is available in Kotlin 1.0.0. The Kotlin REPL is supposed to be stable! JetBrains really need to clarify what is happening with the Kotlin REPL in the Kotlin 1.2 release, will it still be around?
Moving forward there are four possible options for the Kotlin REPL:
Discontinue all Kotlin REPL variants (both terminal and IntelliJ versions)
Only continue development on the IntelliJ Kotlin REPL version (drop the terminal one)
Do just enough maintenance on all the Kotlin REPL variants (basic Kotlin support) but use a third party REPL with advanced Kotlin support (if support is missing then JB or the community maintains the support) like Jupyter Notebook for example (has unofficial Kotlin support, which is lagging behind)
Use JShell (subject to having JVM language support) as the Kotlin REPL replacement (terminal and IntelliJ) and drop support for all existing Kotlin REPL variants
I do think that option 3 would likely be the best course of action. Greatly frees up some resources for JB which can be used to improve Kotlin in other areas (eg develop Kotlin’s multi platform system ), and still provides a very basic REPL (minimal maintenance) which will still be around in future Kotlin releases. It is highly likely that JB will need to ensure there is a stable Kotlin compiler API available otherwise Kotlin REPL support will grind to a snails pace, and fall behind which isn’t a good thing .
), and still provides a very basic REPL (minimal maintenance) which will still be around in future Kotlin releases. It is highly likely that JB will need to ensure there is a stable Kotlin compiler API available otherwise Kotlin REPL support will grind to a snails pace, and fall behind which isn’t a good thing 
.