Chris Vine <ch...@cvine.freeserve.co.uk> writes:
> POSIX system calls are encoding agnostic. The filename is just a series
> of bytes terminating with a NUL character.
Yes, I know, but conceptually these things are strings. Unless you're
going to treat these filenames as black boxes to be copied from one
place to another but never manipulated, printed, or read, you need to
know their encoding and you need to treat them as strings internally.
> All guile needs to know is what encoding the person creating the
> filesystem has adopted in naming files and which it needs to map to.
Right, but how does it know that? The closest thing we have to a
standard way to tell programs what encoding to use is via the locale. I
believe that's what most existing internationalized programs do, anyway.
> So far as filenames are concerned, this seems to me to be something
> for which a fluid would be just the thing - it could default to the
> locale encoding but a user could set it to something else.
We could do that, but I'm not really sure how it would improve the
situation. If Guile expects the program to know the encoding of
filenames on the filesystem, that just passes the buck to the program.
How does the program know what encoding to use?
Yes, the program can know the encoding if it's a custom program written
for one specific system. However, if you write a program that's
supposed to work on any system, how do you know the encoding?
It seems to me that each system must standardize on a single encoding
for all filenames on that system, and the locale encoding is the defacto
standard way of telling programs what that is.
Regards,
Mark
