Prompt on read

[Helmut Eller]

Am I the only who finds it confusing that the read procedure
automatically writes a prompt? E.g.

#|kawa:1|# (read)
#|kawa:2|# abc
abc
#|kawa:2|#

Despite that the prompt in line two is confusing, the line number in the
third prompt seems wrong. I would expect that read works basically like
read-line, which doesn't prompt:

#|kawa:3|# (read-line)
abc
"abc"
#|kawa:5|#

Is there an easy way to disable the prompting in read?

Helmut

[Per Bothner]

Post by Helmut Eller
Am I the only who finds it confusing that the read procedure
automatically writes a prompt? E.g.
#|kawa:1|# (read)
#|kawa:2|# abc
abc
#|kawa:2|#

The read procedure does not write a prompt.
However, when you read from an "interactive port" (implemented using TtyInPort,
when a new line is requested, a prompt is printed.

In other words, in Kawa it's not the REPL that prints the prompt,
but the port itself.

This has the advantage that multi-line input commands get multiple =prompts,
which I think is the correct behavior.

Post by Helmut Eller
Despite that the prompt in line two is confusing, the line number in the
third prompt seems wrong. I would expect that read works basically like
read-line,

Yes and no. read reads an S-expression, and there may be a many-to-many
relationship between S-expressions and lines. A prompt is printed before
each input line - however note it is possible for a procedure to change the
prompt, for example to the empty string.

I agree there does appear to be some mismatch between when a line number
is incremented and a prompt is printed. This is at least ugly.
I haven't looked into why that happens.

FWIW I can't come up with any valid use-case for explicitly calling read on an
interactive port. The problem is error recovery. Enlighten me.

[Helmut Eller]

Post by Per Bothner

Post by Helmut Eller
Despite that the prompt in line two is confusing, the line number in the
third prompt seems wrong. I would expect that read works basically like
read-line,

Yes and no. read reads an S-expression, and there may be a many-to-many
relationship between S-expressions and lines. A prompt is printed before
each input line -

If a prompt is printed before each input line, then why does calling
read-line not print a prompt?

Post by Per Bothner
however note it is possible for a procedure to change the
prompt, for example to the empty string.

You mean something like (fluid-let ((input-prompt1 "")) ...) or
something else? Hmm, that would work for me.

Post by Per Bothner
FWIW I can't come up with any valid use-case for explicitly calling
read on an interactive port. The problem is error recovery.
Enlighten me.

Uhm, a REPL that wants to print its own prompt? Or something like

(format #t "Please enter a filename: ")
(open-output-file (read))

Helmut

[Per Bothner]

Post by Helmut Eller

Post by Per Bothner

Post by Helmut Eller
Despite that the prompt in line two is confusing, the line number in the
third prompt seems wrong. I would expect that read works basically like
read-line,

Yes and no. read reads an S-expression, and there may be a many-to-many
relationship between S-expressions and lines. A prompt is printed before
each input line -

If a prompt is printed before each input line, then why does calling
read-line not print a prompt?

Post by Per Bothner
however note it is possible for a procedure to change the
prompt, for example to the empty string.

(After having to remind myself how it all works ...)

The interactive port does print a prompt at the beginning of line,
if there is a prompt specified. However, the default prompt procedure
depends on the "read state" (i.e. input-port-read-state). If
the read-state is #\newline (which is the default) the default prompt
string is empty (or actually null). The read procedures sets the read-state
as it parses the S-expression.

Now consider:

$ bin/kawa console:use-jline=no
#|kawa:1|# (define r1 (read))
#|kawa:2|# (4 5)
#|kawa:2|# r1
(4 5)
#|kawa:3|#

Why is the line 2 prompt repeated? I'm still trying to figure that out,
but it appears related to the fact that read doesn't read the entire line,
only the "(4 5)". For example read followed by read-line to read
the remainder of the line works as expected.

#|kawa:3|# (define r2 (read)) (define l2 (read-line))
#|kawa:4|# (5 6)
#|kawa:5|# r2
(5 6)
#|kawa:6|# (write l2)
""
#|kawa:7|#

There are also some weirdness with console:use-jline=no (raw console read)
vs console:use-jline=yes (read using jline input library).

Post by Helmut Eller
You mean something like (fluid-let ((input-prompt1 "")) ...) or
something else? Hmm, that would work for me.

That could work.

Post by Helmut Eller

Post by Per Bothner
FWIW I can't come up with any valid use-case for explicitly calling
read on an interactive port. The problem is error recovery.
Enlighten me.

Uhm, a REPL that wants to print its own prompt?

In which case you'd override the default prompt.

Or something like

Post by Helmut Eller
(format #t "Please enter a filename: ")
(open-output-file (read))

Here read-line makes sense but read is clearly wrong.

[Helmut Eller]

Post by Per Bothner

Post by Helmut Eller
Uhm, a REPL that wants to print its own prompt?

In which case you'd override the default prompt.

Yes, I'll do that.

Helmut

[Per Bothner]

I checked in two little fixes in line-number handing of read/read-line in the repl.

The first fix makes line numbers work correctly when calling read or repl-line
from the REPL, at least then the jline library is not used (console:use-jline=no).

(The jline library provides readline-like input editing.)

The second fix was specifically to the jline interface (JLineInPort.java) and causes
the proper line-numbers to be displayed when read-line is called when console:use-jline=yes.

There is still a line-number bug when read is called when using jline.
(The Kawa/jline interface is complicated and this case is mot a priority.)