Rewrites

Bit off more than I could chew. It's now been a week since my last commit, which is usually a signal that it's time to do a revert and start over again. I got most of the code done and was working on debugging, but then I realized there's no way I can verify the quality sufficiently to have confidence in the code I just wrote. So it looks like I'll be scrapping it and starting with a simpler feature addition.

No matter how many times I make this mistake, I always seem to make it once more...

Actually, I may back up all the way and start from a fresh Pylons project (keeping the bottom-up widgets libraries I've developed, of course, which now account for over half the code). Now that we have a better idea of the data structures involved, many of the early attempts at a game compiler just seem like extra cruft. We can also keep the editor, compiler, and game archetypes reasonably in-sync instead of having the compiler and games get way ahead of the editor.

There are a couple of weak spots that I'm still feeling shaky about and want to prototype some more before I build something that'll hopefully be the final version:

1. Worlds larger than the stage. I haven't really played with this in Flash, yet I think it's really important for our initial version. Games are much more fun when there's more of them offscreen. We also need to figure out how to edit them in JavaScript - am thinking OpenLayers or Canvas, maybe.
   
2. Canvas tag in general. Nobody seems to use it, but it may be pretty useful for what we're doing.
3. Expression language. This is a big one; the existing system is pretty ad-hoc, consisting of simple regexp replacements on what is basically ECMAScript. We should have some sort of formal language with error checking and a real parser itself. The existing version isn't even correct in some cases.

I also need to figure out how to reflect our changes immediately in the editor, now that we offer full, composable statements. I figure our options are:

1. Create an interpreter in JavaScript for the JSON "language". Don't really like this one, because then we need to update both the compiler and the interpreter when the language changes, which seems like a pain.
2. Duplicate the compiler in JavaScript, then eval the resulting function string and place it in the appropriate event handler. Same issues
3. Call the backend compiler and have it return a result via AJAX. This seems like the best option in terms of code duplication, but will result in a delay before the change is apparent. This may be acceptable, though, as long as it's only a couple seconds.

Also, I wanted to look at scheme2js and see if there's any usage for that. I'm guessing there won't be - we want to serialize our data as JSON for its cross-language benefits, so we'd just have to compile the JSON version to Scheme. But we do need some way to write library functions that can be used with both MTASC and JavaScript, preferably without the _root.fn nonsense we've got now.

Maybe I should look into haXe too. Last time I looked, there were issues with library support - whatever we use for JavaScript needs to support JQuery and probably Canvas. But at least it'd eliminate the need for MTASC.