I haven't looked in too much detail at the inner workings of the LUA mode, but in general terms..
BlitzMax can compile C/C++ but it doesn't always ( often? ) have the necessary datatypes for you to interact with it directly. That is, it often has the datatypes, but they're not equivalent with their C++ counterparts. For example, structs with anything but the simplest datatypes cannot be interfaced directly from BMax. You end up writing a simple wrapper ( like my TrueVision wrapper ) where you have a BlitzMax Type which mimics the struct and a series of functions which pass the struct/class instance and then operate on it as you wish. To the person using the module, they don't see any difference. They still have a class with the same methods and fields, but you end up writing a lot of intermediate code in order to achieve that. Arrays are the same way, in C/C++ they're stored in a contiguous block of memory, but in BMax, they're not, it's just a block of pointers. So you end up having to fake it with one of a few different measures ( eg: "unfolding" them into separate variables if they're small arrays or writing a wrapper if they're not. )
Now in terms specifically of the LUA modules, as I say, I haven't looked at them, so I don't know specifically why a module is required. It won't be the classes, I guess, because I think I'm correct in saying that LUA is written in pure ansi C, but I assume it will be something like that, perhaps in terms of letting LUA call BlitzMax functions and access BlitzMax arrays. I'm sure Noel, Tommy and others wouldn't have written the module(s) if it wasn't/they weren't required, and it does often seem to be the case that you need some BlitzMax "glue" ( forgive the LUA pun ) to get BlitzMax and C to bond.
BlitzMax can compile C/C++ but it doesn't always ( often? ) have the necessary datatypes for you to interact with it directly. That is, it often has the datatypes, but they're not equivalent with their C++ counterparts. For example, structs with anything but the simplest datatypes cannot be interfaced directly from BMax. You end up writing a simple wrapper ( like my TrueVision wrapper ) where you have a BlitzMax Type which mimics the struct and a series of functions which pass the struct/class instance and then operate on it as you wish. To the person using the module, they don't see any difference. They still have a class with the same methods and fields, but you end up writing a lot of intermediate code in order to achieve that. Arrays are the same way, in C/C++ they're stored in a contiguous block of memory, but in BMax, they're not, it's just a block of pointers. So you end up having to fake it with one of a few different measures ( eg: "unfolding" them into separate variables if they're small arrays or writing a wrapper if they're not. )
Now in terms specifically of the LUA modules, as I say, I haven't looked at them, so I don't know specifically why a module is required. It won't be the classes, I guess, because I think I'm correct in saying that LUA is written in pure ansi C, but I assume it will be something like that, perhaps in terms of letting LUA call BlitzMax functions and access BlitzMax arrays. I'm sure Noel, Tommy and others wouldn't have written the module(s) if it wasn't/they weren't required, and it does often seem to be the case that you need some BlitzMax "glue" ( forgive the LUA pun ) to get BlitzMax and C to bond.