Re: binary-port?

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> ludo@gnu.org (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)':
>
> https://github.com/rotty/spells/blob/master/spells/ports.sls

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.

OK.

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

Thanks,
Ludo’.