Prompt on read

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

Re: Prompt on read

[Per Bothner]

On 11/21/2017 04:44 PM, Helmut Eller wrote:
> 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.

> 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.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Prompt on read

[Helmut Eller]

On Tue, Nov 21 2017, Per Bothner wrote:

>> 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? 

> 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.

> 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

Re: Prompt on read

[Per Bothner]

On 11/22/2017 12:31 AM, Helmut Eller wrote:
> On Tue, Nov 21 2017, Per Bothner wrote:
> 
>>> 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?
> 
>> 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).

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

That could work.
> 
>> 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
> 
> (format #t "Please enter a filename: ")
> (open-output-file (read))

Here read-line makes sense but read is clearly wrong.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Prompt on read

[Helmut Eller]

On Wed, Nov 22 2017, Per Bothner wrote:

>> 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

Re: Prompt on read

[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.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/