> 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
want it.
--
Bradd W. Szonye
http://www.szonye.com/bradd