4 ms·
I don't know what was they reason they chose but a one possible one is that unicode variable names introduce several implementation challenges. You need to worr
by ufo 6y ago
I don't know what was they reason they chose but a one possible one is that unicode variable names introduce several implementation challenges. You need to worry about normalization (the same character may be represented by different byte sequences) and you might need to have large tables to be able to tell whether an unicode character is a letter or a symbol. There are also problems with encodings; UTF-8 vs Latin-1 and so on...
- mumblemumble 6y agoI imagine it wouldn't have been that hard, if the authors had just used ICU4C for string handling. I've had good luck with just converting all input to normal form C. The bigger challenge there is that, if you're using ICU strings, then you've lost the ability to use any library that is designed to work with C strings. There's no way to avoid 0x00 showing up in the middle of UTF-16 and UTF-32 strings, and, even if you use modified UTF-8 to avoid NUL bytes, you still break the assumption that a string's length is equal to its size is bytes.
- ufo 6y agoNot to mention the inherent problem of adding a dependency to an external library. I know that in the case of Lua that was one of the main reasons. ICU by itself would be larger than the rest of the interpreter.