Re: Extending Lua for multiple light userdata types

[Coda Highland <chighland@...>]

On Tue, Nov 13, 2012 at 12:59 PM, liam mail <liam.list@googlemail.com> wrote:
> On 13 November 2012 20:35, Coda Highland <chighland@gmail.com> wrote:
>> On Tue, Nov 13, 2012 at 12:29 PM, Rena <hyperhacker@gmail.com> wrote:
>>> On Tue, Nov 13, 2012 at 3:05 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>>> 2012/11/13 Rena <hyperhacker@gmail.com>:
>>>>> On Tue, Nov 13, 2012 at 10:42 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>>>>> 2012/11/13 Rena <hyperhacker@gmail.com>:
>>>>>>
>>>>>>> Recently I was thinking about how you might add a 64-bit integer type to Lua.
>>>>>>
>>>>>> This is only a pressing question if you need IEEE floats and 64-bit integers
>>>>>> in the same program, otherwise you can build Lua with 64-bit integers
>>>>>> as your `number`.
>>>>>>
>>>>>
>>>>> True, but I really prefer to leave recompiling Lua as a last resort.
>>>>
>>>> How do you envisage accommodating new types without patching
>>>> and recompiling Lua?
>>>>
>>>
>>> ...that was kind of the point of the original post. Already you have
>>> lua_pushlightuserdata(L, p); this could be as simple as
>>> lua_pushcustomuserdata(L, p, n), which functions the same as
>>> lua_pushlightuserdata except for adding n to the "type" value
>>> (LUA_TLIGHTUSERDATA + n + 1, for n = 0 to some appropriate upper
>>> bound), and having those types be something like union { uint64_t int;
>>> uint8_t byte[8]; } instead of void*. You'd only need the initial
>>> change to add this capability, instead of hardcoding new types into
>>> Lua directly.
>>>
>>> --
>>> Sent from my Game Boy.
>>>
>>
>> As I said, if this is something you really want, LuaJIT already does
>> almost exactly that with its cdata type. If you care about low-level
>> data types, you're PROBABLY also interested in everything else LuaJIT
>> has to offer.
>>
>> /s/ Adam
>>
>
> Yes yes, I think we all know where you stand in trying to tell people
> that they need LuaJIT.
>
> This conversation started in IRC and I fully agree with Rena which
> will come as no surprise as I have said this before. It is 2012 and
> yet Lua has no access to a 64 bit int(in fact from the C API point of
> view it was even considered to remove the default lua_Integer as a
> typedef for ptrdiff_t ), before too long the majority of people will
> not care about 32 bit systems and even arm is getting a 64 bit
> version, when will Rio Lua have a 64 bit int? When will we be able to
> sanely do bit operations on 64bit types without resorting using
> strings *?
>
>
> --Liam
>
> * As a side note bit operations in Lua using functions makes me eyes
> bleed, it really needs the power patch applied or something else
> considered because as it is the situation is awful.
>

I acknowledge that there's an exception to be made for 64-bit ints, as
they can't be exactly represented as doubles and you'll generally be
using them for things besides numeric computation (bitmasks for
example). But I think that this one exception isn't worth trying to
add an entire new architecture for "non-pointer lightuserdata of an
arbitrary number of static types" when most of Lua's demographic isn't
going to care about it. It seems like unnecessary complication.

> So, all you want is a bit64 library? This is easily done as long as it
> handles userdata not numbers. If there is any demand for that, I can
> provide an implementation.

And Luiz chimes in as I'm typing my reply, and I agree with that. The
overhead of dealing with full userdata instead of lightuserdata is, I
think, irrelevant for vanilla Lua.

/s/ Adam