[Top][All Lists]

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

Re: binary-port?

From: Ludovic Courtès
Subject: Re: binary-port?
Date: Mon, 25 Apr 2011 16:08:44 +0200
User-agent: Gnus/5.110015 (No Gnus v0.15) Emacs/23.3 (gnu/linux)


Andreas Rottmann <address@hidden> writes:

> address@hidden (Ludovic Courtès) writes:

>>>> However, I’m wondering whether we should not just squarely do away with
>>>> the binary/textual distinction, and just write:
>>>>   (define (binary-port? p) #t)
>>>> What do people with experience with pure R6RS code think?  Is the
>>>> distinction actually used, and how?
>>> I can only find one example in the code I wrote:
>>> `copy-port', which works (with the probably obvious semantics), on both
>>> binary and textual ports.  On Guile, when `binary-port?' would return #t
>>> for all ports, `copy-port' would break, losing the transcoding effect
>>> you'd get when you pass two textual ports of different encodings.
>> Interesting.  Can you post a link to the code?
> Sure, it's in `(spells ports)':

I see, thanks.


> So, my impression is that while `binary-port?' and `textual-port?' are
> not used widely, they do have their uses, and there is definitly code
> out there that relies on the binary/textual distinction.


> - 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.

> 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.


reply via email to

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