From: Mike Gran <spk121@yahoo.com>
To: "Ludovic Courtès" <ludo@gnu.org>,
"guile-devel@gnu.org" <guile-devel@gnu.org>
Subject: Re: The “binary-friendly” Latin-1
Date: Mon, 24 Jan 2011 15:21:53 -0800 (PST) [thread overview]
Message-ID: <55051.1700.qm@web37908.mail.mud.yahoo.com> (raw)
> From:Ludovic Courtès <ludo@gnu.org>
> To:guile-devel@gnu.org
> 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
next reply other threads:[~2011-01-24 23:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 23:21 Mike Gran [this message]
2011-01-25 10:19 ` The “binary-friendly” Latin-1 Hans Aberg
2011-01-25 13:21 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2011-01-26 18:31 Mike Gran
2011-01-28 11:15 ` Andy Wingo
2011-01-29 14:29 ` Ludovic Courtès
2011-01-25 14:01 Mike Gran
2011-01-25 19:58 ` Ludovic Courtès
2011-01-24 22:26 Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55051.1700.qm@web37908.mail.mud.yahoo.com \
--to=spk121@yahoo.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).