option to have locale-independent floating-point constants #999

Contrary to usual programming languages and zsh, floating-point constants in ksh93 depend on the locale for the decimal delimiter (decimal-point character), which is unpractical and surprises users. For instance, the commands

ksh93 -c 'echo $((1./2))'
ksh93 -c 'printf "%g\n" 0.5'

output an error in locales where the decimal delimiter is not the period. This also affects the comma operator when the decimal-point character is the comma:

$ for s in "1,2" "1, 2" " 1 ,2" "1 , 2" ; do LC_ALL=fr_FR.utf8 ksh93 -c "echo \$(( $s ))" ; done
1,2
ksh93:  1, 2 : arithmetic syntax error
ksh93:   1 ,2 : arithmetic syntax error
2

while mksh and bash output 2 in these 4 cases.

Note that printf from the GNU Coreutils accepts both the period and the decimal-point character of the current locale (when different), like GNU MPFR's mpfr_strtofr function. Perhaps this should also be the case for ksh93.

There should be an option to have locale-independent floating-point constants:

• in arithmetic expressions (and only accept the period as the decimal-point character to avoid the issue with the comma operator);
• with the printf builtin (possibly accept both the period and the decimal-point character of the current locale, like with GNU Coreutils, and possibly even without such an option).

Also note that in the ksh93(1) man page (ksh93u+m 1.0.10-5 Debian package):

• "Floating point constants follow the ANSI C programming language floating point conventions." This is not correct since C floating-point constants do not depend on the current locale.
• "It is a good idea to leave a space after the comma operator in arithmetic expressions to prevent the comma from being interpreted as the decimal-point character in certain locales." But a space before the comma operator may also be needed as shown above.

For the reference: #145