[gambit-list] eof-object port property, what do you think?

Mikael mikael.rcv at gmail.com
Fri Jul 19 06:22:31 EDT 2013


Hi,

What would you say about introducing an eof-object property to the ports,
that is #!eof by default?

I suggested there be a way to wrap both IO error and EOF to custom IO
primitive return values in January (
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-January/006322.html),
and Marc gave ports error handler thunks through the io-exception-handler
slot, in the convo from 10 March (
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-March/006486.html)
to 4 April (
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-April/006576.html),
so that the user can wrap IO exception into a custom return value or other
behavior.


Now the ordinary EOF handling remains: in ~12 places over Gambit's
sourcecode, there's an #!eof return value hardcoded. ~2 of these are in C,
though channeled through Scheme code of course.

Adding an eof-object should mean an addition of ~~6 lines of code to
Gambit, and modification of ~~12 lines.


The reason I propose the eof-object property is basically that, if it's set
to #f, IO primitive results can be applied to boolean operators (or and if
cond etc.) directly to get a differentiated behavior between success and
failure, and this really supports code conciseness.



I'm willing to implement this.

Just wanted to ask if you have any thoughts/comments on it?


(
For context, in the longer run, with the IO system, I find
 * finding a way to increase single-byte/char read/write:s from the present
350KB/sec to something much higher, and
 * a way to implement application-level ports (SSL/GZIP/etc.)
really relevant developments, and those are also the only ones I have on my
mind.

Zooming out further, the reason I care about this is because it's struck me
that Gambit's IO system needs to be the facility used for pretty much any
IO or IO stream operations; any approaches with the user implementing an
own streams, 'io primitives' or similar facility will end up severely
limited in comparison with channeling the same functionality through
Gambit's IO system, so therefore the clean solution is to make Gambit's IO
system support these things well too.

Jeff Read who implemented GamSock appears to have had a related take on it,
when he proposed in
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2012-October/006138.html
that
with "`##open-predefined' I will look into the possibility of creating an
"upper layer" for Gamsock that uses port I/O".
)


Best regards,
Mikael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20130719/5cfe08ae/attachment.html 


More information about the Gambit-list mailing list