[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] Add implementation of "transcoded ports"

From: Andreas Rottmann
Subject: Re: [PATCH 4/4] Add implementation of "transcoded ports"
Date: Thu, 25 Nov 2010 01:08:46 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Hello!
> I pushed your patches, thanks!

> Now, I’m slightly worried because now (rnrs io ports) /looks/ complete
> but isn’t quite complete.  :-)

> For instance,
>   - ‘binary-port?’ always returns #t.
AFAICT, there is currently no strictly correct way to tell binary ports
and textual ports apart -- the closest thing I know about is having a
port encoding of latin-1.  Perhaps changing it to test for that would be
at an improvement, although on the other hand, all ports in Guile are
binary ports in the sense that you can do binary I/O operations, such as
`put-bytevector' on them.  So without extending the port infrastructure
to support "disjoint" port types, the current implementation of
`binary-port?' is probably the thing closest to the truth.

>   - Transcoder EOL styles are silently ignored.
>   - Not all the transcoder error handling modes are supported.
>   - Decoding errors are thrown as native Guile exceptions, instead of
>     R6RS conditions.
Thanks for coming up with this list; I'm sure there's more, but "we"
have to start somewhere ;-).

> So I think “we” (i.e., you ;-)) should either implement the missing
> stuff, or raise an exception, or print a warning when the caller asks
> for something that’s not implemented (e.g., EOL style != native), or
> document the current shortcomings.

> What do you think?
I'll try to do a mixture of all three approaches -- i.e. implement stuff
as far as I have time and motivation, fall back on warnings, and
document the remaining shortcomings where warnings are not feasible for
some reason.  How does that sound?

Regards, Rotty
Andreas Rottmann -- <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]