Andy Wingo wrote: > I also don't >know whether to supply an optional "encoding" argument, and use that >encoding to decode the command line arguments.
If you don't fancy the profusion of extra "encoding" parameters on argv access (this ticket), environment access (bug#20822), and all sorts of syscalls (bug#22913), you could bundle them all together in a fluid. This would be a bit like the %default-port-encoding fluid, but setlocale should absolutely not modify it. It should follow the scheme that I laid out in bug#24186: its value can be either a string naming an encoding, or #:locale-at-io meaning that whenever encoding is required the currently selected locale is consulted. There should also be a fluid determining the conversion strategy, like the existing %default-port-conversion-strategy. These two fluids together would control the encoding and decoding for all operations that currently apply the locale encoding to arbitrary data. (Decoding locale-supplied messages is a different matter.) -zefram
