Re: PATCH: math and locale

[Zefram <zefram@fysh.org>]

Bart Schaefer wrote:
>Glancing through /usr/X11R6/lib/X11/locale/locale.alias I see that the
>"POSIX" locale is an alias for the "C" locale, so it probably doesn't
>really matter either way.  Anyone else have an opinion?  Zefram, perhaps?

Well since you asked...

"C" is probably to be preferred, because it will be available in *all*
locale implementations, whereas the "POSIX" locale is a POSIXism.
However, where the locale is already "POSIX", presumably we wouldn't need
to change that, if we're making setting it conditional -- I don't have
the standard to hand, but I'd be very surprised if it defined a different
numeric form.  Data point: setlocale(3) on Linux indicates that "C" and
"POSIX" are canonically equivalent.

>} > Where *exactly* would LC_NUMERIC make any difference in pws-9 ?

Here we run into one of the big conceptual problems with locales.
Are we outputting human text or machine data?  There's a need for both.
locale-aware programs need to consider which category each output
falls into, and perform conversions appropriately.  Unfortunately, the
C locale system provides no way to switch locale on a per-conversion
basis -- not even separate interfaces to perform conversions in the "C"
and current locales.  This is where it all falls down, and programmers
like me just throw up our hands and give up until we're provided with a
usable interface.

If we do wish zsh itself to use locales, I see several possibilities:

* We can do what POSIX defines for most utilities (not sure what it
  says about sh): guarantee sensible behaviour in the "POSIX" locale,
  and leave it undefined everywhere else.  Strictly speaking, if you
  want the standard form of output from most POSIX utilities, you have
  to set LC_ALL=POSIX for it.

* We can use the selected locale for LC_MESSAGES, which only affects
  things that are definitely for human consumption, and leave everything
  else using the "C" locale.  This would have almost exactly the desired
  effect for zsh, and is trivially easy to implement.

* We can try to do it properly: decide which things should be
  locale-dependent and which shouldn't.  We can fabricate a set of
  functions like glibc's strtod_l() (perform strtod() using locale X)
  to make it easier.  Problem: we'd get ambiguous cases.  strftime()
  is particularly nasty in this respect.  However, following this path,
  we could make the whole locale thing much easier for the users of zsh:
  we could provide interfaces where the user specifies whether to use
  locales or not.  ztrftime() could allow a flag in % sequences to say
  "use the "C" locale for this expansion".

Opinions?

-zefram