|read-all| and other Gambit procedures that need to detect eof can use (port-eof-object port) instead of #!eof .

The benefit with a configurable eof object is that if it's #f , the boolean primitives |or| |and| |if| etc. can be used directly on IO primitives' return values.

This scales up very nicely when implementing a DSL that essentially does IO: success means that the IO did not fail, that the data formats it expected to get were correct, etc., and #f means there was an error;

For instance i lower-level code that performs protocol handling such as HTTP and SSL, you tend to do single-byte and other accesses where the primary question all the time is, if there's EOF, and then only secondary to that is the logics for handling a successful read/write . This is the kind of places where a #f eof-object would help code conciseness alot primarily, and speed secondarily; the alternative in these settings would be to create wrappers atop Gambits IO primitives that wrap #!eof to #f , and this just does not scale code-wise, and it feels a bit like a waste to do that in single-byte access-based code where speed is the main prio.

What do you say?

Best regards,
Mikael


2013/7/31 Marc Feeley <feeley@iro.umontreal.ca>
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@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@iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list