Possible to determine type of record at runtime?

[ewmailing]

Is it possible to determine the type of a record at runtime?

I wrote myself into a little hole where this would be useful. I have several similar record types which I thought I could keep completely separate in their usages. But I have a case now where they relate to another, it would be really convenient to place 'any' of these records into a list of {any}. But when I retrieve them from the list, I need to be able to figure out which kind of record it is.

Incidentally, I have been thinking to keep separate lists internally, but this will force me to create multiple API calls to cover all the combinatorials the different types can be put together. I'm thinking function overloading to handle different types might be a really nice feature here for callers of that API set. I've also been thinking function overloading would have been convenient for handling some Lua APIs that can take different number of arguments and types.

[hugomg]

AFAIK there isn't a way to do it yet. But we'd be very happy if someone wrote a pull request for that :) I believe it shouldn't be too difficult to implement, and I could show you the ropes if you're interested. Currently the IR already implements the special cases "isNil" and "IsTruthy" and this would be a natural generalization of that.

[srijan-paul]

We're already storing the type names in the metatable field (IIRC) so it would be a great idea to add this functionality.
+1

[ewmailing]

I need to get through tax season before I can take on any new projects, so it will be a couple more months.

But I was also poking at the const ticket. I would expect to benefit from optimizing global const variables since I like to use that pattern a lot. But compilers are not my area of expertise, so I was unable to glean any ideas on how to implement this by looking at the code. I am curious if the const support or this problem is easier. And would getting a walkthrough of how one of those works directly be applicable to the other?

But perhaps my biggest question is, what is the roadmap of the C FFI? For me, that is potentially the most valuable thing.

[hugomg]

The roadmap is unfortunately a bit stalled, because I'm busy with other stuff lately (and because there aren't any lablua students actively working on the codebase). The last news about FFI is that we had someone design a prototype, but it didn't get to a point where we could merge it into the mainline.

One thing that I would love to hear a suggestion from you, is what do you feel might be a bare minimum useful ffi. I think the long term goal is to get something similar to what gabriel made. But until then, I wonder whats the simplest possible thing that is still useful.

Ps.: I'll try to see if I can find a copy of Gabriel's thesis online. If I don't find it until next week, plz ping me again to remind me.

[ewmailing]

So for the project I'm currently working on, the bulk of things I do is loop through arrays of floats or integers to calculate things. (I decided to try Pallene because it seemed like this is the type of thing Pallene would be really good at.)

So keeping with that theme, there are some useful libraries written in C that I would like to access so I don't have to rewrite all these algorithms in Pallene. (And in potentially a few cases, a few of these C functions may be highly optimized using SIMD intrinsics, which I can't do in Pallene.)

So an FFI that I can easily bind to Pallene so I can pass and use arrays of floats and integers would be my starting base case.

• But in addition to that, my hope is Pallene can generate a more efficient binding than can be done with the standard Lua API. As you are aware, there is non-trivial overhead with individual element access of a C userdata as an array from the Lua side.

In Pallene, when I create typed primitive arrays in Pallene, you now seem to have optimized that really well. My hope is you can do something similar for C bridged arrays so I can frequently access individual elements on either side of the bridge without all the traditional overhead.

As for other bare minimum things, I think the usual suspects:

• easy way to bind simple C functions that use primitives (float, integer, boolean, maybe string)

• If we could also push structs/records through the FFI, that would be awesome, but maybe this doesn't need to be part of the "bare minimum" for me right now.

• Longer term, I do have a lot of thoughts...I won't write up everything but here are two teaser things:

  • annotations for in/out values and for multiple return values
  • optimizations for arrays of records (not pointers to records)
    • graphics/game engines really want to be able iterate fast through arrays (minimizing cache misses) while being able to do this in Lua/Pallene... consider an array of structs often contains elements comprised of some combination of x,y,z,w / r,g,b,a / u,v

[ewmailing]

Ps.: I'll try to see if I can find a copy of Gabriel's thesis online. If I don't find it until next week, plz ping me again to remind me.

Just thought I would bump this :)

[hugomg]

I looked all over my files and haven't found it. I'm asking some friends to send me a copy and will post it online when I get it.

[hugomg]

Hi there! Sorry for the delay. I finally managed to track down a copy and uploaded it to the lablua website. You can find it under our Publications page.

http://www.lua.inf.puc-rio.br/publications.html
http://www.lua.inf.puc-rio.br/publications/2021-GabrielDePaula-msc-dissertation.pdf

[ewmailing]

Very interesting. I only had a chance to skim it. I plan to re-read the paper with more focus when I finish my immediate obligations for this coming month. I would really like to see the source code if you can find it.

[hugomg]

Source code is in the ffi branch of Gabriel's fork of the repository: https://github.com/GCdePaula/pallene/tree/ffi
Having another person take a look at it would be much appreciated, as I haven't had the opportunity to look at it in depth myself. The main thing I would say for now is that be aware that there are some weird things in the current implementation, which kept it from being merged into the main repo. For example, the way it has a separate parser and lexer for the FFI bits. Anyway, if questions come up that I can't answer, we should be able to forward them to Gabriel.