Hi, Andreas Rottmann <a.rottm...@gmx.at> writes:
> l...@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’.