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

Marc Feeley feeley at iro.umontreal.ca
Wed Jul 31 11:09:46 EDT 2013


Adding a configurable end-of-file object to ports causes a problem with the read-all procedure (and maybe others).  It expects read to return #!eof to indicate the end-of-file.  If the end-of-file object is configurable how can the end-of-file be detected reliably?

Marc

On 2013-07-19, at 6:22 AM, Mikael <mikael.rcv at gmail.com> wrote:

> 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
> 
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list



More information about the Gambit-list mailing list