New port implementations

[Jim Blandy <jimb@red-bean.com>]

Tim Pierce writes:
>Perl handles this problem by telling the stdio library, essentially,
>"please go away."  The record input routine in Perl calls read() to
>read chunks into a buffer, and then scans the buffer in core for
>delimiter characters.  In some ways that's the Right Thing, since it
>permits doing all kinds of funky things with delimiter strings and
>buffered input that are harder to do if you rely on stdio.  But in
>order to use *any* stdio functions (and ultimately that's just about
>unavoidable), Perl has to use the stream's own buffer for all of this
>work, and that creates monstrous portability headaches.

Then, Per Bothner writes:
>Michael R Cook <mcook@cognex.com> writes:
>> Every implementation of fgets I've seen has been simple repeated
>> invocations of getc.
>
>Well, ones I have seen (and written), are smarter than that.
>For example the implementation in libio (which I wrote, and
>which is used in glibc), plus the BSD 4.4 implementation.


If anyone is interested in working on a better port implementation for
Guile (possibly modeled on libio), please speak up.  I'd like to
improve Guile's I/O performance, provide more versatile primitives
(like Perl's), and allow layering (encrypted ports, compressed ports,
and so on).