What needs said

[Josh @ Dreamland]

Okay, I think it's about time to answer the obvious question: Why are you so interested in a new parser?

The C parser needed fixed to get the project working again on Linux, due to changed headers. I decided that it would be a good time to do some re-thinking of the parser system in general.

A lot has changed since the project began, and not just with my views on what ENIGMA should be. I wanted ENIGMA to be free, fast, capable, and cross-platform from the start. In the time since then, Yoyo has set similar goals. They have proven to—as far as commercial organizations go—not be very capable of attaining those goals. However, one of the achievements they have made is getting Game Maker to work on every platform ENIGMA does. In fact, they've gone a step further and made it easy to get GM working on those platforms; presently, ENIGMA takes some finagling. In addition to working on those platforms, GM can export to JavaScript. This changes the rules of the game in itself.

With that turn of events, it is time to take Rusky's advice from two years ago. Well, not all of it. Some of it still makes me want to puke (and he no longer defends it, either). Unfortunately, I went ahead and threw the baby out with the bathwater on that one.

While originally, the plan for ENIGMA was to leave the bulk of interpretation to the host language (ie, C++), doing so has closed the doors to a number of language features.

I have designed JDI in such a way that ENIGMA will be able to reuse the vast majority of its code (in addition to using all of it to being the C++ backend).

What that means is the availability of this feature set:

•   A unified language and corresponding AST whose backend language does not matter.
  • Ability to export to any language from the backend.
  • Ability to accept definitions from any language capable of reflection (and C++) as the frontend.
•   Ability to declare getters and setters on certain variables
  • The possibility of adding quad trees to collision systems by placing setters on x and y.
  • The ability to assign a getter for variables such as bbox_left, object_count, etc.
•   Ability to replace operators with methods
  • No more div/mod class. Simple to cast division operands to double.
  • Simple to implement boolean xor, [snip]^^[/snip].
•   Ability to determine the type of any expression used in code.
  • Full control of instance or class access through the dot operator.
  • Ability to decide whether or not to cast operands to division (eg, determine whether the class has a division operator overloaded).
  • Ability to regulate the ternary operator to ensure against ambiguity (eg, [snip=edl]var a = string_mode? "" : 0;[/snip]).
• Ability to resolve overloads of functions
  • Ability to use a more efficient overload for varargs functions.
  • Ability to pass additional arguments to certain functions.
    • Ability to pass information about the current instance and other instance to functions implicitly.
      • Replacement system for the central iterator system, which is founded on globals.
      • Ability to call instance modifying functions from threads.
             
       

Maybe you can see how I'm excited about the prospect. If not, questions here.

[Josh @ Dreamland]

I'm bumping this, because I'm starting to think that people don't view the front page and therefore cannot see this post.
I'll post a new newspost later regarding progress on the operation. Edit: Actually, maybe I'll just post it here.

I have basically completed getting JDI working on the major platforms (Linux, Windows, Mac OS). The parser completes with less than 300 errors on Linux; I can't give a good estimate on Mac/Windows because I am not the one who tests it on those platforms. While 300 errors may seem like a lot, it really isn't a big deal, because JDI easily recovers from them and continues reading definitions. That's a good behavior to have in a parser whose only objective is to inform on the basics.

Right now I am further reducing that error count and finishing up the parts of JDI upon which ENIGMA's new EDL parser will depend. ENIGMA will, in principle, be able to invoke JDI methods to handle a good amount of EDL parsing. This means that I only have one parser to maintain rather than two; if one is right, both are right. It also means that ENIGMA's lexicography will match that of G++, so we shouldn't have any inconsistencies except due to utter negligence.

I'm going to knock off a few more errors and then begin the new parser methods to build ASTs of entire codes. Since the system will operate with JDI as a basis, you will be able to render your code as an SVG to diagnose any misinterpretations (and, of course, to show it off to your friends ).

Anyway, I'll report back on how that goes when I'm actually starting the EDL parser. Ciao.

Update: On Linux, I have it down to 215 lines of errors; of those, there are 86 separate errors (problems in the parse process), caused by 21 unique issues with the parser. That last figure, 21, is the number you need to be concerned with. For now, I'm going to leave it, unless correcting the bug that seems to involve the preprocessor is necessary. The preprocessed Windows engine only throws 187 total lines of errors, which means to me that either Windows is much more parser-friendly, or there is a bug with JDI's preprocessor.

[forthevin]

The latest version of the jdi-branch still works well under 64-bit Ubuntu 12.04, apart from the true/false issue.

"Ability to export to any language from the backend." Does that mean, in theory and with enough work, JDI could export to JavaScript?

"Ability to declare getters and setters on certain variables." and "The possibility of adding quad trees to collision systems by placing setters on x and y." is great, and should help speed up collisions a lot.

[Josh @ Dreamland]

JavaScript was the very language I had in mind. We already have a JS engine started, and it of course supports execute_string.