guile-devel
[Top][All Lists]
Advanced

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

Re: binary-port?


From: Andreas Rottmann
Subject: Re: binary-port?
Date: Tue, 26 Apr 2011 02:16:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Hi,
>
> Andreas Rottmann <address@hidden> writes:
>
>> - Ikarus and Ypsilon definitly have disjoint ports.
>>
>> - Racket natively has ports that will accept both binary and textual
>>   operations, but it's R6RS support wraps these ports so that the
>>   resulting R6RS ports are not compatible with Racket's native port
>>   operations, but do provide the binary/textual disjointness.
>
> So Racket really has 3 disjoint port types, right?  That looks
> inconvenient to me.
>
It is, at least if you don't deal with R6RS-mode code only.  It's a
similiar situation (although not as pervasively inconvinient) as the
mutable/immutable pair division.

>> These are the only implementations (besides Guile), that I'm familiar
>> with.  Ideally, Guile's R6RS support would provide real disjointness for
>> binary and textual ports -- I think the only artefact that hampers this
>> is that there's no way to distinguish Latin-1 encoded ports from "pure"
>> binary ports (as both have `port-encoding' being #f).
>
> And beyond that, you can put-bytevector on any port, read-char on any
> port, and so on.
>
> I wouldn’t want the “native” port type to be disjoint from the R6RS port
> types, notably because there’s no “native” equivalent to the R6RS binary
> I/O API, and also because it would hamper composition of R6RS and
> non-R6RS code.
>
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?

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>



reply via email to

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