 |
lua-l archive |
|
|
||
|
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 compatibility' module.
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 libraries.
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.
My 2c.