The "make the special type in C" journey and type

[Andrew Starks <andrew.starks@...>]

On another thread, the "make a library in C" solution was pointed out
as a way to mitigate a lack of a specific value type in Lua. This was
what was done for me by LHF when I needed 64 bit ints. (thank you!) It
has worked well.

While extending Lua functionality by exposing C *functions* is utterly
painless and transparent, extending lua by exposing *types* is not
transparent.

The stumbling block that I had to resolve was using this new type with
the standard libraries, which were looking for "number." I wrapped the
standard functions so that they would check if they were userdata, but
I wanted to know that they were actually the userdata that I was
hoping for. It didn't seem right to call int64.tonumber or to
otherwise perform the math without knowing that I was looking at what
I was expecting.

I was able to solve it by simply monkey-patching `type` so that it
used the debug library, grabbed the name of the library[1] and
replaced type's answer with my more specific variant, which was
"int64". Then I added the same capability to my own "types", such as
my real number objects, etc, through a "__type" metafield[2].

Had I ignored this and simply called `int64.tonumber(my_int)`, then I
could just let the library throw the error---no need for any change to
`type`. If I'm writing the module, this is the best approach. When I
am not, then I like to throw the error because I wrap my error
function to work with my logging library. Also, I usually change the
level of the error to that of the caller, which is not how many
libraries do it and wouldn't be "knowable" by the library's author,
anyway.

I'm not making any sort of proposal[3] and I won't suggest how this
could be done at the language level[4]. My purpose is to point out
that recommending that someone "use a host language library to create
the type that you want in Lua" is not as simple as it is when
importing a C function because Lua does not offer a facility to tell
the difference between one kind of userdata and another, except to
rely on the module's author to provide one. This is not always done in
a way that is terribly consistent or trivially parsed.


Thanks!

-Andrew


[1]  Thanks to a convention that was followed by Luiz.

[2] This has worked well for me. I don't notice any issues with speed
or other libraries. I'm sure that I'm actually wrong and that it
doesn't work well for me, ;), but I'll learn that lesson later.

One critique that I do have of my method is that it is overbuilt in
the wrong ways. In retrospect, simply making `type(my_int)` return
"int64" and then make a `rawtype(my_int)` return the "Lua" value would
have been a simpler solution. I blame Lua for being fun to program in,
when I overbuild.

[3] I tried to make this as helpful as possible. I respond well to
respectful criticism of my writing and I welcome it.

[4]  I'll go back and try to dig up old conversations about "type" and
why things are the way that they are.