 |
lua-l archive |
|
|
||
|
Le 22/11/2016 à 06:25, Dirk Laurie a écrit :
For the part which enable to use other lexems than the default reserve ones, the idea is to make that only through a loadable scope contained feature.But (finally returning to the topic of the thread) the fact that APL and Lua for all practical purposes inhabit different lexical worlds makes it possible to write a single interpreter that mixes APL and Lua at use input level. I'd hate to give that up. Si I guess that I don't want internationalization in standard Lua. Call it Lua-i18n as the OP said, but please keep that i18n in the name at all levels. Don't call it Lua.
For the internationalization of error messages, it should not introduce any change in the language interpretation. Possibly this might have an impact on the executable size, but it also might have some way to manage that as an optional feature at compile time so you get zero extra weight. Possibly you may even scrape some bytes with a "null" locale which get rid of messages or at least use void string. Feedback is welcome if you have some suggestions on this topic.
For the unicode support, I don't yet have enough knowledge to forecast what the consequence would be. But once again, this might be implemented as an optional feature at compile time. You might even think of more character encoding if you are nostalgic of the good old ISO 8859 mess or that you have some peace of software that you need, can't make evolve, and rely on non-ASCII character encoding.
Which point would still sound problematic to your mind? Can you please provide some details, possibly with an concrete code example of how it would be problematic to you?