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&#39;s sourcecode, there&#39;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&#39;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&#39;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&#39;s struck me that Gambit&#39;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, &#39;io primitives&#39; or similar facility will end up severely limited in comparison with channeling the same functionality through Gambit&#39;s IO system, so therefore the clean solution is to make Gambit&#39;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 &quot;`##open-predefined&#39; I will look into the possibility of creating an &quot;upper layer&quot; for Gamsock that uses port I/O&quot;.</div>

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