On Tue, Mar 10, 2009 at 5:08 PM, duck
<duck@roaming.ath.cx> wrote:
>> There's probably a good reason why this is not already part of lua, can
>> anybody shed some light on this ?
> To avoid bloat
This is a non-argument, since the additional code needed inside the Lua
parser would be minuscule.
>and also because the perfect place for such a feature is
>in a text-encoding library
I couldn't disagree more.
You might argue that the place for strings encoded in decimal would be in
an external library, since it's very unusual to use decimal notation for
this purpose.
But hex notation, as proposed, is:
1. the de facto standard for encoding "unprintable" ASCII characters in
strings, both in program code and on the web,
2. the most readable and reliable way of encoding ASCII into a numeric
representation, since every character takes exactly the same number of
bytes,
3. specifically designed to simplify mental recognition of bit patterns
within a byte,
4. a perfect fit for the by-design layout of the ASCII character set
itself.
>Also, it is trivial to write it in Lua:
This is a non-argument. Firstly, your proposed code leaves literal strings
twice the size they need to be in the compiled code. Secondly, your
notation doesn't allow hex-encoded characters to be embedded in human
readable parts of strings. Thirdly, your code introduces significant
(well, on embedded devices) run-time overhead into every program which
uses hex-encoded strings.
I'd hazard a guess that the memory space required for he two translation
tables in your code would greatly exceed the space required for adding
support for ...\xAA... into the Lua parser :-)
Use of hex-embedded chars in strings is almost ubiquitous; use of
decimal-embedded characters is...well, it had never occurred to me to do
it until I came across Lua.
IMO this is one issue where the speedily vocal minority in the Lua
community are in the right, and ought promptly to win, and where the
authors should quickly concede defeat...
