Not necessarily in order of importance or ease of implementation!
- Specify which line editor is preferred
- Don't prompt user about Linenoise on Windows
- Be able to turn off Linenoise/Readline/rlwrap hint
- Suppress Linenoise/Readline/rlwrap hint if running under rlwrap
- Persistent history
- Multi-line input
- Multi-line history
- Add tab completion to Readline
- Move the REPL code into Perl 6
- Improve tab completions
- Bake docs into Rakudo for use in REPL
- Handle CTRL-C
- Persist result of previous evaluation in a variable
- Reload libraries
- Persist the current "workspace"
- Intelligent Multi-Line Prompt
- Fix other situations with multi-line input
- Figure out how to handle compile-time constructs in multi-line input
- Allow correction of syntax errors
- Automatically enter debugger on resumable exceptions?
- Allow -I to affect $*REPO in the REPL
- Start a REPL during execution
Right now, Readline is used if available. If not, Linenoise is used. If
neither is available, plain old I/O is used.
Having a setting like RAKUDO_LINE_EDITOR would be nice if users prefer Linenoise,
or if other line editors are available in the future.
Currently, if a line editor module is not loaded, we print the following:
You may want to `panda install Readline` or `panda install Linenoise` or use rlwrap for a line editor
With Windows cmd.exe or Powershell, the user already has a simple line editor, so they don't need this hint. We may want to remove this hint entirely, or amend it to say something like "for @features[], install Readline or Linenoise"
I imagine that some people may get annoyed by the above hint; we should have a way to turn it off.
If rlwrap is our parent process, we don't need to display the hint.
It would be nice if history persisted between sessions.
History files should be under ~/.perl6/rakudo-history by default (now, what ~ means is another story; CompUnit::RepositoryRegistry interprets it as the first of $HOME or "$HOMEDRIVE$HOMEPATH"
This path should be overridable via RAKUDO_HIST.
A user should be able to enter the following:
for ^10 {
.say
}
and have the REPL do the right thing.
If you're in the middle of multi-line input, and you enter something like this on accident:
my $s = greet('hello
you can figure out the sequence of characters you need to type to close the expression, but it would be nice if there were a shortcut to bail you out.
History should be aware of multi-line entries.
The readline library itself supports custom tab completion; the Perl 6 binding just needs this added.
Having to write NQP to extend the REPL is LTA. There's nothing wrong with NQP, per se; but
I think it would lower the barrier to entry for new users to contribute to enhancing the REPL,
plus this way we don't need to recompile CORE.setting if we change it, unlike for Perl6::Compiler.
The way the tab completer gets the term to complete is LTA, as is the list of completions.
Not entirely a REPL task, but it would be awesome if, for example:
List.can('eager').WHY
...would return the documentation for List.eager as found on docs.perl6.org.
Having a help() function or something like that might help new users get acquainted with the language.
CTRL-C should aborting the currently running statement if there is one, or clear the current line of input if not.
Like _ in Python or ans in Octave.
One thing I've liked about other language environments is the ability to reload code, so I can work on a module in my editor, and then keep trying it out in my REPL. This might be out of scope of the REPL shipped with Rakudo, but it might be nice as a ecosystem module.
One thing I like about R is that I can save the current workspace to an image, whether I'm running a program or working in a REPL. That way, if a failure occurs, I can restore the image and debug the problem. This would also probably be a ecosystem module.
It would be nice if the multi-line prompt indicated which character(s) are needed to complete an expression, similar to psql or zsh. For example:
> for ^ 10 {
brace * .say
brace * }
For example:
> my @a = [
or
> my $b = <
For example:
> class C {
* has $!attr;
* }
For example, instead of this:
> for ^10 {
* .say;
* ]
===SORRY!=== Error while compiling <unknown file>
Missing block
at <unknown file>:3
------> <BOL>⏏]
>
You would get this:
> for ^10 {
* .say;
* ]
===SORRY!=== Error while compiling <unknown file>
Missing block
at <unknown file>:3
------> <BOL>⏏]
* ]
Notice how the last line is * ]; this change would allow you fix your mistake without having to enter the whole multi-line expression again! Of course, if multi-line history is done right (where you can edit the full multi-line entry by hitting Up), this might not matter.
It might be nice if a debugger were entered upon an uncaught but resumable exception.
PERL6LIB currently works, but -I does not.
Make it really easy to get into a REPL from any point in the program (similar to binding.pry). For example:
sub foo {
my $x = 5;
MY::p6repl; # this will start a REPL in the current context
}
And in this case the REPL instance would be running in the given lexical scope, so could see (and ideally modify) $x.
Example:
> class C {}
> class C {}
===SORRY!=== Error while compiling <unknown file>
Redeclaration of symbol C
at <unknown file>:1
------> class C⏏ {}
expecting any of:
generic role
No curses-like or GUI interfaces; I think that these belong in ecosystem mdoules.
- nREPL (from Clojure)
- Pry (from Ruby)