Hi,<div><br></div><div>What would you say about introducing an eof-object property to the ports, that is #!eof by default?</div><div><br></div><div>I suggested there be a way to wrap both IO error and EOF to custom IO primitive return values in January (<a href="https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-January/006322.html">https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-January/006322.html</a>), and Marc gave ports error handler thunks through the io-exception-handler slot, in the convo from 10 March (<a href="https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-March/006486.html">https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-March/006486.html</a>) to 4 April (<a href="https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-April/006576.html">https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-April/006576.html</a>), so that the user can wrap IO exception into a custom return value or other behavior.</div>

<div><br></div><div><br></div><div>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.</div>

<div><br></div><div>Adding an eof-object should mean an addition of ~~6 lines of code to Gambit, and modification of ~~12 lines.</div><div><br></div><div><br></div><div>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.</div>

<div><br></div><div><br></div><div><br></div><div>I'm willing to implement this.</div><div><br></div><div>Just wanted to ask if you have any thoughts/comments on it?</div><div><br></div><div><br></div><div>(</div><div>

For context, in the longer run, with the IO system, I find</div><div> * finding a way to increase single-byte/char read/write:s from the present 350KB/sec to something much higher, and</div><div> * a way to implement application-level ports (SSL/GZIP/etc.)</div>

<div>really relevant developments, and those are also the only ones I have on my mind.</div><div><br></div><div>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.</div>

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

<div>)</div><div><br></div><div><br></div><div>Best regards,</div><div>Mikael</div><div><br></div>