[Date Prev][Date Next][Thread Prev][Thread Next]
- From: Duck <duck@...>
- Date: Thu, 8 Nov 2007 00:27:35 +1100 (EST)
I'm still of the opinion that the Lua core should stay clear
of NLS functions. I.e. replace ctypes with an internal table,
replace l_strcmp with memcmp and move that strcoll mess to
loslib.c or (better yet) to an 'ancient single-char NLS
I'm not very knowledgeable about i18n and l10n, but I think I agree
wholeheartedly with this.
That Lua strings and the string library behave, internally, in some weird,
locale-specific, yet utterly locale-limited, way seems to be a waste of
time. (That's at best. At worst, it makes it completely unreliable to run
Lua programs at all. On many platforms, run-time environment variables,
which the Lua core can't and shouldn't have to predict, can alter the
behaviour of apparently clear and simple code.)
My own opinion is that core Lua strings (and library functions) should
simply be 8-bit clean binary blobs. Intrinsic character groups -- for
example, "upper case alpha" -- should be based on unexceptional,
internally hard-wired, "7-bit ASCII in 8-bit chars" tables/behaviour.
American? So what. It's at least consistent (and as simplifications go,
perhaps the most immediate and the most effective.)
Whatever else thou wantest, providest thou it thyself. Using optional
If you want a program to behave variously depending on which environment
variables have been set to control some non-Lua library code which Lua
happens to have used on your platform...then require a relevant
module to allow this particular effect.
Unless you are going to provide true i18n/l10n features (e.g. "would you
like to switch interactively from French to Hebrew, and then from Hebrew
to Traditional Chinese) then why not provide a US-ASCII flavoured solution
only in the core? Americanisms like "A-Z are the built-in alpahabetic
letters" are surprisingly generic and useful, yet also compellingly
simple, and easily implemented. If you want to do beter than that,
require() a module with supports you in your betterment.