Okay, sorry this reply took so long; it took insanely longer than I thought to the compiler building correctly again, but now it's mostly up with the new system and I can at least use it to prepare a response.
1. Bogus for statment.Your [snip=edl]for (i = 0; i < stuff; i += 1;) {}[/snip] is actually the less bogus of the two for() issues. The weirder one is [snip=edl]for ({i = 0;} i < stuff; { i += 1; } ) {}[/snip]. The raw output for the two of these in the new parser is as follows:
Warning(Code,38,6): Blocks not actually allowed in `for' parameters
Warning(Code,38,26): Blocks not actually allowed in `for' parameters
Warning(Code,38,33): Semicolon should follow statement at this point
for ((i) = (0); (i) < (stuff); (i) += (1);)
{}
for ( (i) = (0); (i) < (stuff); (i) += (1);)
{}
It doesn't warn about the trailing semicolon, and in fact, includes it in the output because the dump function always puts a semicolon after statements. The C++ pretty-printer will not do that.
In fact, more work will need done in the pretty printer to support the latter for() loop, as it is basically unsalvageable. Code output will look like this instead:
{
{i = 0;}
while (i < stuff) {
{}
continue_destination:
i += 1;
};
break_destination:
}
The pretty-printer already needs to be able to support custom break and continue labels in order to support [snip=edl]continue 2[/snip].
2. Checking for inequality with <>.When I wrote the old pretty-printer, I'd forgotten about <>. It pretty much indiscriminately puts spaces everywhere. Output for [snip=edl]if a <> b c = d[/snip] is as follows:
if ((a) <> (b))
(c) = (d);
3. Giving a variable the name of a C++ data type or the name of a function.Yes, its silence on the matter is an issue. The new parser accepts the code as well; this is its text-dump:
((alarm)[0]) = ((100) - ((random) (int)));
The AST tells another story:
I haven't decided if I want it to bitch out in a frenzy or let the pretty-printer salvage it (which, as you can see, is possible). In compatibility mode, the lexer will not honor "int" as a type, and the problem becomes moot, so really, it's in the air. I have a little more work to do to help scope resolution in the AST builder anyway, so we shall see.
4. Resources that would have the same name, if not for an asterisk one of them has.Asterisks are invalid in resource names in GM and ENIGMA alike. GM doesn't care because it is in charge of the entire AST, anyway. ENIGMA is in charge of the AST only until it is converted to C++. While it was originally supposed to be LGM's job to verify resource name integrity, during my rewrite of practically everything in the compiler, I decided to handle this myself. A correct structure name is now generated for the objects up front, and objects themselves are referred to exclusively by ID during print.
5. Other stuff you probably know about already.dll functions: These are implemented in Windows using libFFI. The same code can be ported to Linux with very little modification (only what is required to use the system FFI library instead of the one included in ENIGMA for Windows).
ini functions: I think someone started working on these, but probably got bored. No one uses INI anymore, so they've been given pretty low priority.
execute_string: This is implemented in EGMJS, and is liable to stay that way for quite some time. Otherwise, a substantial portion of the compiler must be included with the engine; it's just messy. ENIGMA is compiled, not interpreted.
variable_local_exists: In C++ (among other compiled languages), a variable can't conditionally exist. A key in a map can conditionally exist. I might implement this for var and variant, but the truth is, there is
never a good reason to use this function. Its only valid use case in GM is to work around the stupid order in which Mark handled instance creation codes in rooms (room instance creation code was fired before instance creation code). In ENIGMA, as well as in later versions of GM, this has been corrected.
user_event: I have a bigger, better plan for these that doesn't involve Mark's shoddy, pathetically finite and otherwise very ugly and limited implementation of "User events". Think local scripts.
event_inherited: I wanted polygone to implement this as practice. Never happened. So I guess I'll handle it while I finish recoding the rest of the compiler.
sprite_create_from_screen: I thought someone had coded this by copying my implementation of screen_save. I guess that isn't the case, but for anyone whose interested, this can be written by copying my implementation of screen_save.
file_exists: I can't believe this isn't implemented. On Windows, this is [snip]CreateFile()[/snip]. On Linux, this is [snip]stat()[/snip].
I was already aware of most of this stuff, but I don't mind a refresher.
