This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> 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