[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strings draft
> Bradd W. Szonye wrote:
>>>> 2. Use your native language, and include the locale metadata at the
>>>> start of the file (e.g., wrap the file with something like
>>>> #,(LOCALE UTF-8 EN-US ( ... )))
Alex Shinn wrote:
>>> I like this, though I still disagree on the input locale. Perhaps:
>>> #,(ENCODING "UTF-8"
>> I don't understand what you're getting at here. I must've missed
>> something earlier in the conversation.
> I was just suggesting it can be useful to have a way to specify the
> character encoding of Scheme source, a separate issue from locale, much
> like the XML: <?xml encoding="utf-8"?>
OK, I see. I didn't mean to imply that one *must* specify both encoding
and language. Nor was the example syntax dear to me. Actually, I think
your modeline-style comment is a good idea, and so is Shiro's "declare"
form. Anyway, I think it's useful to have the option to specify the
source encoding, the language/collation conventions, or both.
>>>> 3. Use your native language, and rely on local system conventions to
>>>> change the default Scheme locale.
> No, I understood fine. I ... consider it a horrible design flaw to
> even allow the possibility of code that may or may not be an error
> depending on the user's locale, whether or not the user in question
> cares about i18n.
I don't think it's any worse than code that depends on particular
compiler extensions or libraries. While I personally prefer to use
standardized features, I don't have a problem with people relying on
locale extensions like this. Of course, something like this probably
*wouldn't* be standardized or SRFI'd, but I thought it was worth
mentioning as an example of what an implementor might do, if the users
Bradd W. Szonye