[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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
> I have no idea where you got this impression.
- I misspoke, likely getting too late on my end, I apologize.