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

[Dirk Herrmann]

On 9 Mar 2001, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:
> 
>     Dirk> Well, if I remember right, you actually wanted to provide a
>     Dirk> general buffered-input-port rather than just a line-buffered
>     Dirk> input port, and that's what my suggestions was targeted at.
> 
> OK; what do you think of the diff below, where I've made the
> interpolation of a character such as newline optional, and off by
> default?  Would you still prefer to remove the interpolation option
> completely?

Well, yes, because this can easily be solved by the reader function, even
if it requires to do some string-append stuff.  What is the problem with
that?  I don't see any benefits to put this into the definition of the
port.  (Well, yes, one could argue that this is better, performance
wise.  But I don't buy such an argument if it means to compromise an
otherwise clean interface.)

> 
>     Dirk> But, again: I am not any more convinced that the current
>     Dirk> implementation of line-buffered input port deserves a module
>     Dirk> of its own, since it is too specifically designed around the
>     Dirk> use in the repl.  We should, IMO, rethink that decision.
> 
> I agreed that it is targetted at use in repls.  But (a) I don't think
> this is the only possible use, and (b) even for repls, there are many
> possible repl implementations, and it makes sense for them to share
> common code.

But, what if 'char-ready?' was available for soft ports (as you
suggested)?  Then, all the special repl stuff could be extracted. If we go
that way, everything is nice and beautiful.

BTW:  The comment for make-soft-port seems to be ahead of its time:  It
says that a soft port is characterized by 6 parameters :-)

Best regards,
Dirk Herrmann