> 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
