LÖVE

As far as the database thing goes, you might be able to make a facts / rules system along the lines of this:

Query system

or the "Query Compiler" chapter of this:

On Lisp

(Since you mention "Code is data" I assume you're not afraid of parentheses. )

I've been planning to experiment with this approach for my company's next project, which is likely to be AI-heavy. Nothing handy right now, though.

Some interesting sort-of-related work in Metalua:

Pattern matching
Example Metalua implementation

Star Crunch wrote:As far as the database thing goes, you might be able to make a facts / rules system...

That's not a bad idea. I was thinking of whipping up a dialogue database editor with Glade/PyGTK and posting it here if anyone expressed interest in it, but then I realized that LOVE currently has no kind of database support

Star Crunch wrote:Some interesting sort-of-related work in Metalua:

Pattern matching
Example Metalua implementation

Metalua sounds awesome! My favorite part of Lua has always been the bytecode and VM, the language I could do without, really, it kinda nauseates me. Is Metalua usable/mature? (Just to be clear, I'm not suggest using MetaLua to skirt Lua's original syntax!)

I haven't had a chance to try it yet. That's also on the TODO list. (I have immediate practical applications for it, e.g. using the code walker tools to auto-generate private keys for instance variables, which is now a painful exercise and results in a sea of brackets.)

From reading around on the Metalua blog and mailing list, and looking at the author's samples, it certainly seems respectable. I think these guys have been doing quite a bit of vetting on the libraries they add, and they saw fit to include it.

According to this the current version is in pure Lua again, so it should be usable from Löve.

Star Crunch wrote:I have immediate practical applications for it, e.g. using the code walker tools to auto-generate private keys for instance variables, which is now a painful exercise and results in a sea of brackets.)

I think I sorta follow that one. Care to explain it? Maybe PM if people are offended by OT posting.

Care to explain it? Maybe PM if people are offended by OT posting.

Elsewhere our SABDFL threatened to ban the first one to stay on topic...

Basically, to keep access private, you need keys that can't be guessed.[1] This rules out strings (and numbers and booleans), but anything that you can generate and store locally is fine. Tables are the least verbose. Most of my class files begin with something like
and then when I access them throughout the code I have
which gets to be a lot of brackets.

My thinking is, so long as I maintain some easily identifiable convention (in this case the leading underscore), I could instead write it as
and, using the Metalua code walker, search the file for the underscored fields, generate the private keys out of sight (probably favoring something more lightweight like "function() end" over "{}"), and properly inject them into the code.

I'll probably post a fairly basic demo of some stuff today or tomorrow, if you want to look through and see what I'm doing now.

[1] Also, a simple table won't work because somebody could just pass over it with pairs() and collect the keys. I get around this now via a userdata generated by newproxy(). This thread covers the details pretty well, and at the end Roberto seemed inclined to add some protections into how __pairs and next() will interact in Lua 5.2.

Star Crunch wrote:

Care to explain it? Maybe PM if people are offended by OT posting.

Basically, to keep access private, you need keys that can't be guessed.[1] This rules out strings (and numbers and booleans), but anything that you can generate and store locally is fine.

This is exactly what I thought you meant, and it's a pretty ingenuous reach-around for getting private variables in Lua. In Javascript you can get private variables using closures, but you have to bludgeon proper prototypical inheritance to get it

Your technique also reminds me of one of the ideas I have written in a notebook on programming language design. The idea would simultaneously knock out two features: enums, and "secret keys" as you describe them. The rule was that if a variable was referenced before being assigned to, it was automatically assigned a unique value!