[gambit-list] eof-object port property, what do you think?
mikael.rcv at gmail.com
Thu Aug 1 09:31:28 EDT 2013
|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'
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?
2013/7/31 Marc Feeley <feeley at 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?
> 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 (
> and Marc gave ports error handler thunks through the io-exception-handler
> slot, in the convo from 10 March (
> to 4 April (
> so that the user can wrap IO exception into a custom return value or other
> > 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.htmlthat 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list