Re: [Chicken-users] Request for a read-string! variant

[Alejandro Forero Cuervo]

> From: Alejandro Forero Cuervo <address@hidden>
> Subject: [Chicken-users] Request for a read-string! variant
> Date: Sun, 11 Jul 2010 13:03:30 +0200
> 
> > I want to write something akin to the following C code:
> > 
> >   char buffer[BUFSIZ];
> >   int len;
> >   while (0 < (len = read(fd, buffer, BUFSIZ))) {
> >     consume(buffer, len);
> >   }
> > 
> > I'd rather not consume characters one by one —as I'm somewhat
> > concerned with efficiency— but, on the other hand, I would rather
> > consume inputs as soon as they are available to my process (because
> > the file descriptor may be a socket, which may wait for a reaction on
> > something it sent before sending more).
> > 
> > What would be the recommended way to do this in Chicken Scheme?
> 
> Currently not possible, but I see the point.
> 
> > I noticed that there is a read-string! function but, upon inspecting
> > its source, it seems to, inconveniently, iterate until it has filled
> > the buffer provided (as opposed to just returning as soon as
> > fast_read_string_from_file has returned).  Maybe we should make
> > read-string and read-string! just return after
> > fast_read_string_from_file, rather than iterate?  Given that the
> > caller already has to deal with fewer characters returned than
> > requested (since the EOF may have been reached), I think this would
> > provide a much better interface (since it would also support my use
> > case).  If there's concern about backwards compatibility, could a new
> > function with this behavior be provided?
> 
> `read-string' currently reads a given number of characters or
> everything up to EOF. If I understand correctly, you want to have a
> mode that reads "as much as is currently available". Does this apply
> to other port-types, besides network input?

Close: I want a mode that reads "as much as is currently available but
not more than X" (or, in other words, behaves as closely as possible
to the underlying read(2) syscall).

If one has a procedure that does this for a port, it is trivial to
derive from it a procedure that does what we currently have —"read X
characters, stop if EOF is reached"—, but the converse is not true
(hence this whole conversation).  This derived procedure would have
reasonable performance (probably comparable to what we have right
now).  I think the return-soon-if-no-more-input-available interface is
preferable, as it is more expressive.

Yes: it applies to more than network input.  I care about file
descriptors in general (in particular, I also care about pipes).  I'm
building a ropes library (I want to stop using streams of characters
for Svnwiki for several reasons that are not relevant to this message
but that I'd gladly expand on) and I'm writing a “port->rope”
procedure that returns a rope that reads characters from the port as
needed (lazily, similar to the “port->stream” function from the
stream-ext egg, in the end providing some logic somewhat similar to
how Haskell handles strings).  I would like to be able to use this
procedure for any kind of ports, without having to special-case the
different types.  I can't use the existing read-string! function
because the caller of my library may want to process things
line-by-line (for network input or input from pipes/terminals).  Right
now I'm using a procedure that reads input char-by-char (and converts
chunks of chars read into a string that is returned), but I suspect
this is much slower than what I could do if this function was
available.

Thank you for your help!

Alejo.
http://azul.freaks-unidos.net/