Re: Read-line bug in STk 4.0.1 - missing control-Ms.

From: Ian Wild <ian.wild_at_eurocontrol.be>
Date: Mon, 27 Dec 1999 17:34:28 +0100

"Harvey J. Stein" wrote:
>
> Ian Wild <ian.wild_at_eurocontrol.be> writes:
>
> > I think read-line is the WRONG place to do this - it should
> > be an option affecting the whole file once, not each
> > individual access to it. Have you considered an approach
> > like Tcl's [fconfigure]?
>
> So you're suggesting a (port-options) function or set of functions?
> Sounds reasonable. Alternatively, one could have the port creation
> fcns take arguments for this, but there're so many different port
> creation fcns that that'd add up to a lot of changes.

...and some, like with-input-from-file, have nowhere to put
the options anyway.

 
> Actually, it'd be much better to have a function to do this than to
> hang the options off the port creation fcns because the latter doesn't
> allow one to change the options. Consider using a package which
> returns a port. If the package opens the port with newline conversion
> turned on, but you *really* need to get the data verbatim, you'd be
> stuck.

Real world example: you read HTTP headers line by line, but
after a blank line you need to slurp in raw binary according to
the Content-length: field.


> I also
> find it a little scary to think that low level fcns like read-char
> might read multiple characters to get one character.

Not much of an example to follow, perhaps, but that's
exactly what C's getchar() has to do on an MS-DOS machine.

> Especially
> worisome is using char-ready? with read-char to get non-blocking
> reading. Consider char-ready? returning #t because a \r can be read,
> but read-char hanging because the \n isn't ready yet.

Hmmm...hadn't thought of that one. Can't it return #maybe :-)


imw
Received on Mon Dec 27 1999 - 17:45:46 CET