[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The “binary-friendly” Latin-1
From: |
Mike Gran |
Subject: |
Re: The “binary-friendly” Latin-1 |
Date: |
Mon, 24 Jan 2011 15:21:53 -0800 (PST) |
> From:Ludovic Courtès <address@hidden>
> To:address@hidden
> Cc:
> Sent:Monday, January 24, 2011 2:26 PM
> Subject:The “binary-friendly” Latin-1
>
> Hello!
>
> Do we really want to keep:
>
> 1. The notion of a “binary-friendly” ISO-8859-1 encoding? It’s
> actually mostly gone with the iconv change, since every textual
> access goes through iconv. For binary accesses, the right API is
> (rnrs io ports) or similar.
An equivalent question is if you care about backward compatibility of
legacy ports. Legacy ports returned strings and were once the only option.
I think it is a bad idea if you are replacing one non-RNRS port system
with another non-RNRS port system. It is a less bad if you are replacing
non-RNRS ports with RNRS ports, assuming, of course that R7RS doesn't just
invent yet another port system.
>
> 2. The #f <=> "ISO-8859-1" equivalence for ‘port-encoding’ and
> ‘set-port-encoding!’. Likewise, commit
> d9544bf012b6e343c80b76bd5761b1583cc106a3 makes ‘port-encoding’
> always return a string and pt->encoding always be non-NULL.
Is the cost of doing the various string comparisons of port-encoding
strings negligible? It was put in as a (premature) optimization.
>
> Sorry for questioning this now, but these are important questions, I
> think.
Indeed.
>
> Thanks,
> Ludo’.
Thanks,
Mike