Re: Proposed change to `make-readline-port'

[Dirk Herrmann]

On 5 Mar 2001, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
> 
>     Dirk> On 4 Mar 2001, Neil Jerram wrote:
>     >> How about `make-buffered-input-port' and `(ice-9
>     >> buffered-input)'?  [...]
> 
>     Dirk> I like that.  However, it seems that the implementation that
>     Dirk> you have posted was indeed line buffering oriented, [...]
> 
> Of course you are right - silly of me to have missed that.  So I think
> I think it is best to keep the module name `(ice-9 buffered-input)'
> but change `make-buffered-input-port' to
> `make-line-buffered-input-port'.
> 
> (We could later think about removing the line-based assumption, but
> I'd rather not consider that change right now.)

If I understand things right, you have to add the newline because it is
not part of the characters that are returned by readline.  Why not just
let the reader function append the newline character before returning the
string?

>     Dirk>                                 And, with respect to the
>     Dirk> definition of the reader procedure that is passed to
>     Dirk> make-buffered-input-port: I suggest not to pass this
>     Dirk> procedure a boolean parameter.  If I see it right, this
>     Dirk> parameter could easily be avoided if the reader procedure
>     Dirk> itself stores some local state, for example: (define
>     Dirk> (make-example-line-port) (make-line-port (let*
>     Dirk> ((continuation? #f)) (lambda () (display (if continuation?
>     Dirk> "... " "New read: ")) (set! continuation? #t) (force-output)
>     Dirk> (read-line))))) A similar approach can be taken in
>     Dirk> boot-9.scm.  This avoids the use of object properties.
> 
> Unfortunately, not quite, I think.  Only the body of
> `make-line-buffered-input-port' knows when a character has been read
> out of its internal buffer (`read-string').  Consider for example the
> following input (with readline activated and therefore passing through
> this code):
> 
> guile> 44 '(incomplete
> 44
> ... input)
> (incomplete input)
> guile> 
> 
> I believe that we previously agreed that it is correct in this case
> for the second prompt to be `...'.  This is only possible if
> `make-line-buffered-input-port' somehow tells the reader procedure
> that characters have already been read.

I think you are right.

Best regards,
Dirk Herrmann