Tim,
>A number in Lua is stored compactly and does not incur any memory-management overhead to speak of, while a table-driven model is FAR more expensive.
I should've been more specific-- I'm talking about two things at the same time and lacking specificity with both. On the one hand, there is the underlying architecture, on the other there is the language as a UI. From a UI point of view, everything is a Table AND an _expression_ is a powerful idea and not dissimilar from LISP. If a table is an _expression_, the evaluation of a table and the use of the variable that represents that table are conceptually interchangeable. It might be prudent to call it a Telescoping Paradigm. The programmer defines the program in tables, which are expressions to the compiler. When the compiler evaluates an _expression_, it expands sub-tables until it finds a value. Memory is always scope-limited, thus the evaluation of a table replaces the representation of the table itself, which should mitigate the need to manually manipulate memory. We're then using tables to represent expressions that focus on values in a one-way relationship. To simplify matters, values passed into sub-tables would always become local- since the _expression_ represents a table, the evaluation is an aggregation of data- thus we can always modify the super-table with a sub-table by packing changes into the evaluation (much like how tail calls work in Lua already). This way all subroutines are a 1-to-1 mapping of inputs and outputs (apart from requests to hardware).
This would suggest overhead, but it's more about creating a programming paradigm, not necessarily a compiler that works that way. IE- What if every simple data type was padded with extra bits for a potential pointer? A small amount of overhead which allows for every type to become a table if needs to be.
Integer Blah = 4; --Create an Integer
Blah.dino = 10; -- '.' operator generates a table if none exists, appending 'dino'=10 into it.
I imagine there are some tricks that you could use with the nesting of unions and structs to achieve this idea with little overhead. You could also create a scope-local rec where a variable+key hash points to the desired value so you're instead dealing with the scope-local table instead of expanding the overhead of simple types themselves- hey, that might actually work well, no?
Getting a little far away from Lua, sorry about that >_<. Your replies are really enlightening and I can feel my stupidity being sucked out of my head.
>If you go down this path you are creating a language much more focused on meta-pogramming, and this cane get very complex very quickly. In some ways, much of the complexity of C++ is directly traceable to its attempt to be both a general purpose language and a meta-language. I think it's a tribute to the Lua designers that they created a language that is both compact and yet still gives 80% of a meta-language (and, imho, the other 20% is the "dangerous" 20%).
I like the idea of a meta-language that can define itself, much like how boolean algebra is 'complete', and there isn't any conceptual problem with creating a unified syntax to accomplish that. I would contend that the problem with C++ is that the implementation just inflated the language with special keywords and type restrictions that inherently complicate the programmer's impression of what is going on- It's just a bunch of shortcuts. I'm value-neutral about this when it comes to using the language, but from a design perspective I think it's stupid. Could that 20% be made accessible in a manageable way with a different paradigm? While I'm ill-equipped to the task, it's an idea I want to toy with. I've been considering going back into academia, and something like this is what I'd want to do.
Sean,
> You might think that a ton of bits are wasted, but that's the nature of C. C guarentees that the fields will appear in the order given. A lot of CPUs can't reference 32-bit quantities on odd addresses (or even on addresses not divisible by 4). So padding is a given.
In regards to implementation, can you not wrap structs in unions? Not sure about the following semantics,
struct foo { bool b0 : 1; bool b1:1; bool b2:1; /*etc...*/ };
typedef union { struct foo bar; } LByte8;
Obviously you still need to align it to bytes, but you could concievably make your own tables of bits and manually manage pointers/data within it. My understanding of unions/structs is that the given example doesn't produce any overhead and works at compile-time. Though ofc the extra memory for pointers and cycles for bit-masking might contradict any performance gains, but you could probably even make custom pointer tables that consume less memory (relative to the region of bits that you're dealing with, specifying length and position) and access the table at constant time-- the only issue is the cycle-cost of bit-masking, which could be mitigated with some lazy compression. Or is the way C already does it just infinitely superior?
> Can you address individual bits? Yes ... but at a cost. A cost that most people aren't willing to pay actually.
I'm pretty clueless on this-- are the costs any different from what I described above? Are these costs always stupid? I get the sensation that what I'm thinking about here is just moronic... or rather, not applicable. It's just a scheme for data compression without compromising access time... though the overhead to make it work, if there are a lot of new mask-checks, wouldn't be acceptable at runtime, no? Ehh- it's just too domain-specific I guess.
Jay,
> C++ also has the tacit requirement that almost nothing can have greater than O(sizeof(operands)) runtime cost.
Can you elaborate?
> I believe it is the intent that no Lua program, even incorrect ones, can have truly arbitrary behavior. Or put another way, you can't bring down the runtime; it takes C extensions to do that.
Oh- yea, I would never expect Lua to move in that direction. Lua is amazing and awesome the way it is- I'm just getting curious about how it's designed and how it works. Whenever I finish up with current projects, I quickly see myself dumping python for Lua.
Thanks for indulging all these newbie questions!
