guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Neil Jerram
Subject: Re: Proposed change to `make-readline-port'
Date: 05 Mar 2001 20:01:18 +0000
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5

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

    Dirk>                          (BTW: No wrapping with begin is
    Dirk> necessary for 'cond' clauses).

Unnecessary packaging removed - thanks.

    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.

Best regards,
        Neil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]