Better command-line handling

[Michael D. Adams]

As it is now, Ikarus processes anything entered on the command line s-exp by s-exp. This can lead to surprising results if the user enters more than one s-exp on a line. Ikarus should only begin executing the input when all s-exp are closed. And only one prompt should be displayed (right now is shows one per s-exp). (This is probably wish-list and may even become obsolete once readline support is added.)

$ ikarus
> (display "(+ 1 2)")(display (+ 1 2))(newline)
(+ 1 2)> 3>
>

$ ikarus
> (display "Hello")(display (+ 1
Hello> 2))(newline)
3>

[Abdulaziz Ghuloum (aghuloum)]

On Nov 28, 2007, at 3:48 PM, Michael D. Adams wrote:

> Public bug reported:
>
> As it is now, Ikarus processes anything entered on the command line
> s-exp by s-exp. This can lead to surprising results if the user
> enters
> more than one s-exp on a line.

This may be surprising, but to whom? All scheme implementations that
I've used exhibit the same behavior, but that doesn't make it right.

> Ikarus should only begin executing the
> input when all s-exp are closed. And only one prompt should be
> displayed (right now is shows one per s-exp).

Try the attached script and see if it has a better behavior.

> (This is probably wish-list and may even become obsolete once
> readline support is added.)

It certainly is a wish list and readline support is an even bigger
wish :-)

Aziz,,,

[Michael D. Adams (mdmkolbe)]

That looks about right. I did find one possible bug in the script.

$ ikarus
> (+ 1
2)
(+ 12)
>

I'm not sure if that just an output problem or if it read "1\n2" as the number 12 instead of as the two tokens 1 and 2. (My guess is that you pulled out the lines "(+ 1" and "2)" and appended them instead of taking the lines "(+ 1\n" and "2)\n" and appending them.)

BTW, I just tested the equivalent on python and bash, they both make use of a secondary prompt. You may want to consider including that when ever you get around to implementing all this (again no rush, I'm just making sure it's written down). After thinking about it, the secondary prompt solves a small HCI problem: currently in Ikarus forgetting to close a paren (or just miscounting) produces the same output as a long running program, namely no output, but with a secondary prompt, an unclosed paren becomes immediately obvious. (Also user input is clearly distinguised from program output, but at the expense of being able to copy/paste from multi-line input).

Examples:
$ python
>>> (1 +
... 2)
3
>>>
$ (echo 1 2
> echo 3 4)
1 2
3 4
$

[Michael D. Adams (mdmkolbe)]

Found another strangeness:

$ ikarus
> (read)(read) ; trying to issue two reads, but the second gets read as data
(read)
> (read)abc ; example of what is going on
abc

[Abdulaziz Ghuloum (aghuloum)]

On Nov 29, 2007, at 11:54 PM, Michael D. Adams wrote:

> Found another strangeness:
>
> $ ikarus
>> (read)(read) ; trying to issue two reads, but the second gets read
>> as data
> (read)
>> (read)abc ; example of what is going on
> abc

Yeah, that's just like:

 > (read-char)
#\linefeed

The issue boils down to this:

Scheme and Lisp have the notion of a Read-Eval-Print loop. If you
understand what Read, Eval, and Print do, you can explain how the
repl is behaving. What you're proposing here is a Read*-Eval*-Print*
loop: read all expressions, eval them all, then print all results.
While some new users may consider the current behavior strange, some
older users may consider the proposed behavior very strange and
nonconventional.

[Abdulaziz Ghuloum (aghuloum)]

BTW: Kent is releasing chez 7.4 soon which features a really good repl (multi-line history, paren-matching, tab completion, etc). I think I'll just wrap petite with a small script and let it communicate input/output/interrupts to ikarus. This would give us good repl for free (almost).

[Abdulaziz Ghuloum (aghuloum)]

Is there anything to do for this bug report or should it be closed?

[Michael D. Adams (mdmkolbe)]

Well the behavior of ikarus has not changed since the bug was opened. So I guess you have two options. Either say the current behavior is what you want to keep or change the behavior.

My gut preference would be to go with Read*-Eval*-Print* (or maybe Read*-(Eval-Print)* or perhaps Read*-Eval*-Print-only-last-like-a-begin-would). But maybe I haven't thought it through enough.