"The Moon Won't Shine"

"...It's broken down" to use Eric Clapton's words.

Lua. Enemy of mine. I love the language, don't get me wrong. But I spent oh so many nights on my Lua VM that now I burst into tears every time I glance at the project file in Windows Explorer.

First and foremost, while I believe Lua source code is highly optimized C, it kinda looks obfuscated. It gets quite hard to understand what's going on, so hard that I haven't managed to understand how function calls work. And this makes me very sad, angry, people hate me, and I hate the world. There's a lot of pointer mumbo-jumbo to maximize speed.

Calls are pushed on a "call stack". They seem to contain stack top and stack base information. However, a lua thread has a notion of stack top too. You'd think the current call info on the call stack has all the info you need in order to push values at the right index; but no, there are about two stack tops, and the macro hell makes everything even more difficult to understand.
This is more a practical problem, rather than an issue with the language itself.

Something more interesting would be discussing about the possibility of porting Lua on the CLI. I bet as soon as .NET 4.0 will be out, there will be a plethora of language implementations on the DLR.

Anyway. Lua is a strange beast, strange in the sense that Lua values just can't map to POC objects. This means that you have to implement proxy objects that wrap the same semantics of a Lua value. Not good. Quite bothersome. Prone to run slow - slower than the original C implementation, and especially so in a VM that would decode bytecode on the fly. I have faith in IDynamicObject of the 4.0 FCL.

Practical doubt: what if the Compact Framework got runtime code generation as well? All my efforts in creating a Lua VM would become useless. And right now, seeing as I can't unravel the mysteries of the Lua implementation, I'm not even enjoying the effort in making one. Yes, I have a better picture of how Lua works, but no, I don't have a full, clear picture.

Annoying.

As usual, if you don't know what you're going to code in advance, things are bound to become a mess. I thought I nailed function calls, as the output of a few test scripts would yield exactly the same results of the original Lua VM - however, things got crazy when I had to implement protected calls and coroutines. And vararg parameters. Not enough analysis, and that's the result.

For the record, it is just wrong in my opinion to use VES exceptions (oh, fancy details) to change the program flow of a Lua script (which in turn calls plain old CLI methods). The implementations I've seen just do that, seeing as the original C code uses setjmp, longjmp facilities, or C++ exceptions if #DEFINEd to do so; and it becomes hard to model Lua errors in a different way. However, I think it is possible to avoid using Exceptions (costly) with a not-so-nice set of flags that should be checked in strategic places. This might produce code that is not as readable, but it's bound to perform better. In this case, I think it might be worth to sacrifice readability - yes, purists will cry and all.

I've also discovered F#. I have too many things to do, and since work has highest priority (go live closer and closer), chances of getting any of my personal projects done gets slimmer and slimmer with time.

F# is very cool. But damn it, functional programming seems to require some kind of CS education, which I do not have.

Another challenge. Yeah.

That's about it, thanks for reading.

Nerd joke I came up with while talking with a friend some time ago:
"You don't have to kill me; just set me to null, the garbage collector will take care of the rest". I thought it was fun. :P