This page is part of the web mail archives of SRFI 52 from before July 7th, 2015. The new archives for SRFI 52 contain all messages, not just those from before July 7th, 2015.
> From: "Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx> > I strongly disagree. Compilers have traditionally required all source > input to have a particular encoding, usually the system's "native" > character encoding, and it works well. ... - Yup "native", that¹s why they do it. > Huh? I don't recall insisting that compilers *must* recognize only a > single source encoding. Indeed, I've suggested ways to portably specify > the input encoding in source code (in XML style). However, I also think > the traditional "only recognize one source encoding" compilers are also > fine. In other words, flexible source encoding is a desirable but > optional feature. - "portably specify the input encoding in source code (in XML style)"? really, I'm not aware of any broadly accepted file formats which specify their contents in "XML" or any other style for that matter; would be nice, but don't see how one count on it. > No. But it sounds like you *think* I do. Again, it sounds like you have > an axe to grind and are reading too much into my words. - you're probably correct that I'm reading too much into your words, but shy of any universally accepted tagged external data/file format, I see no option but to enable scheme programs to read/write data minimally the hosts natively specified formats, and ideally in an arbitrarily specified one; which seems conspicuous by its absents in the Unicode proposals. > I have no idea where you got this impression. - I misspoke, likely getting too late on my end, I apologize. Thanks, -paul-