Re: [ANN] Lua 5.2.1 (work1) now available

[Xavier Wang <weasley.wx@...>]

2012/3/22 Rebel Neurofog <rebelneurofog@gmail.com>:
>> Lua 5.2.1 (work1) is now available at
>>        http://www.lua.org/work/lua-5.2.1-work1.tar.gz
>
> First, the are some disadvantages I suppose:
> 1. No more simple pointer comparison in C to test string equality.
> Following example shows why:
> #include "lua.h"
> #include "lauxlib.h"
> #include <stdio.h>
>
> int main ()
> {
>    lua_State *L = luaL_newstate ();
>    char big_string[1024];
>    memset (big_string, 'c', 1023);
>    big_string[1023] = '\0';
>    int i;
>    for (i = 0; i < 10; i++)
>        fprintf (stderr, "%p - this is supposed to be the same\n",
> lua_pushstring (L, big_string));
>    return 0;
> }
>
> Simple pointer comparison is needed for fast string constant to C enum
> resolving.
> This is very fast trick when string is pushed into Lua registry and
> returned pointer
> is saved into binary key matching structure created right after lua_newstate ().
> Pointer to that key matching structure is resolved after getting
> allocator user data
> with lua_getallocf (). I may write such library if someone is
> interested (I'm planning
> to implement the method in my project but didn't get to this yet).
> 2. Such change may break reliance on fast comparisons of huge string
> (say check for buffer equality in text editor). So this may hardly modify
> optimization approaches by shifting bottle necks significantly.
>
> Here's my vision:
> 1. Lua strings are currently perfect and should not be changed.
> Experienced Lua programmers have detailed understanding where and how
> (e. g., "table.concat ()")
> Lua strings should be used and where shouldn't.
> 2. Situations with byte arrays (especially mutable) are usually worked out by
> creating project-specific user-data based modules to work with.
> Here's my way for example:
> http://devel.nomrhis.net/Client_API_reference/modules/bytea
> Of course it's not designed for mainstream Lua.
> 4. I think there should be standard common mainstream Lua module
> (and also sandbox-safe as 'string', 'math' and 'table') for processing
> mutable byte array
> with fixed length given at creation time.
> 5. It is probably possible to implement reallocation of data block
> given by lua_newuserdata ().
> Although it may give problems with multithreaded Lua...
>
> Conclusion:
> Lua strings have significant advantages which shouldn't be broken by
> intension to create
> absolute universal data type for all things.
> Instead standard mutable byte array should be implemented on top of user data.
>


Yes, I also don't like this solution. I think add a new mutable string
type is better. the original string is just as Symbol, and new string
is Byte array. thus will produce a mechanism to implement safe program
such like http server.

the new string can be based one userdata or a new type of string. to
make a new string type based work1 is easy: just make all string as
usual, and makes std library return new string type. Lua can offer C
API to create/manipulate the new string type. or just add a
lua_pushbuffer and a new type LUA_TBUFFER and let remains as usual.
and can make a new 'buffer' module to modify the buffer type. just
like my buffer module ( http://github.com/starwing/lbuffer ).

buffer can have hash field, if you compare buffer or use buffer as the
key of table, just calculate hash for buffer, using random seed to
calculate several bytes of buffer (but not all). buffer's pointer are
not the same and you can not compare buffer with pointer. lua_tobuffer
will return char* but not const char*

to add buffer type in work1 is not hard. it's worth to try it :-)