Hi Andreas,
Andreas Rottmann <a.rottm...@gmx.at> writes:
> Well, I'm not advocating making them disjoint in the sense that the
> textual or binary operations are only possible on "matching" ports.
> Allowing to mix binary and textual I/O on any port, is, IMHO, a fine and
> reasonable implementation-specific extension that Guile provides. What
> I'm after is making `textual-port?' and `binary-port?' establish a
> partition on the set of possible ports; i.e.
>
> (textual-port? X) = (not (binary-port? X))
>
> for any port X (or at least for any port obtainable via R6RS-specified
> procedures). For that to work, we somehow need to distinguish between
> Latin-1 ports and "pure" binary ports. Perhaps by adding a flag
> indicating this to the port objects? This flag would then be set by all
> R6RS procedures specified to create binary ports, and would be checked
> by `binary-port?' and `textual-port?'. Additionally, we might want to
> clear that flag when the port's encoding is changed to non-#f. WDYT?
I think we could just as well change ‘textual-port?’ to
(define (textual-port? p) (not (binary-port? p)))
So you would have the illusion of disjoint types, with the important
difference that:
1. All I/O operations can be used on all ports.
2. Using textual operations or ‘set-encoding!’ irreversibly makes a
port pass ‘textual-port?’ if it didn’t already.
WDYT?
Thanks,
Ludo’.
