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.
At Fri, 6 Feb 2004 15:30:47 -0800, 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 ( ... ))) > > > 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"?> However, in retrospect SRFI-10 is a poor way to implement this because it means you can't read the whole list and then dispatch on ENCODING. Probably best to directly copy XML style and have something similar to SRFI-22 specifying the encoding at the top of the file, perhaps hidden in a comment a la Emacs: ;; -*- encoding: UTF-8 -*- > > > 3. Use your native language, and rely on local system conventions to > > > change the default Scheme locale. > > > > This as I pointed out with the Turkish "i" problem is a *Bad Thing* > > which I think everyone agrees we should avoid. > > I suspect that you misunderstood the point of this feature. It's for > people who don't care about internationalization; No, I understood fine. I just 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. -- Alex