Implement a REPL

[gilch]

Basing one on IPython might be a good idea. We'd also get a Jupyter kernel out of it.

[gilch]

#39 is merged. I think it still needs some work.

[gilch]

In particular, it starts a kernel subprocess, sleeps 1 second, and then launches jupyter console. This is brittle. If the system is too busy, the console may try to start before the kernel is ready. Increasing the sleep time by more than a couple of seconds would be annoying most of the time.

I feel like there should be a better way to do this, but I can't find good enough documentation. The obvious way (passing jupyter console the subprocess list) was deprecated, and I can't seem to make it work anyway. Installing the kernel seems to work globally, even if done in a virtualenv, and I can't seem to make it work anyway (although we will want this feature working eventually).

Waiting until the kernel prints something might be good enough. Or maybe I can have it retry a few times. Unfortunately, it will include a "keeping kernel alive" message on exit, and I'm not sure how to stop that either.

Minor nit, the REPL will ask for more lines if ': ' or ':\n' is included in the input (because it might be a multiline hotword expression), even if it appears in a string literal. Not that big a deal for interactive use (just hit enter again), but could be better. I'm also not sure if this will affect doctests.

[gilch]

Some edge cases in how the REPL asks for more lines:

In [16]: (print(': '))
    ...: 
:
In [14]: print:
    ...:  '''
    ...: 
    ...:  '''

Maybe something like Lissp's SoftSynatxError could work. I think I want a better test harness before messing with this too much.

[gilch]

See #61 and #63 for the SoftSyntaxError point. I think it's working better, but untested edge cases are a concern.

[gilch]

Trouble:

In [23]: print:
    ...:  'x'
x

It should have asked for another line. Yes, this much is valid, but more would also have been valid so ending here is premature.

[gilch]

Minor nit, the REPL will ask for more lines if ': ' or ':\n' is included in the input (because it might be a multiline hotword expression), even if it appears in a string literal. Not that big a deal for interactive use (just hit enter again), but could be better.

Simple regex can't distinguish these edge cases. Not that they'd come up much. Distinguishing them seems harder. I'd have to at least write a proper lexer. But duh, I've already got one of those in the parser module. I can just use that.

[gilch]

#64 fixes the regression and the nit.

[gilch]

A REPL is certainly implemented now (and has been for some time), it just has some problems, which ought to be tracked in separate issues. Closing.