The Catch-22 of MOXI--Need some Mynx to get MOXI

I've been down and out of late, but continuing Mynx--albeit slowly.

The Catch-22 with MOXI and Mynx

In implementing the external semantic checks for Mynx, one curious paradox has arisen. The external semantic information files for Mynx classes - MOXI files, are strict XML read into an internal form of a MOXIObject. The Catch-22 is a Mynx compiler is needed to create a MOXI file for a Mynx class, but to further develop, test, and implement the Mynx compiler a set of MOXI files is needed. Doh! It is a chicken-and-egg style paradox.

Resolution of the Paradox: A Bit of MOXI

Unlike the philosophical or logical paradoxes and conundrums that have no immediately apparent solution, the solution is simply not to think in terms of for a Mynx compiler to create MOXI files, and MOXI files for a Mynx compiler.

Mynx compiler => MOXI files, MOXI files => Mynx compiler, etc. ad nausea...


The MOXI files are needed, and the paradox is that it seems MOXI files must only come from a Mynx compiler, and a MOXI file is needed to further test, implement, and develop the Mynx compiler. But a MOXI file need NOT come from a Mynx compiler. Realizing this, the Catch-22 is no longer a paradox. The implicit presumption is that a MOXI file must come from a Mynx compiler.

MOXI without Mynx

A MOXI file can be generated by hand, which is exactly how I wrote the MOXI related classes. But hand coding an XML file is a bit tedious if the MOXI file is for a class with many methods, constructors, and operators. The resolution is to use both Java's and C#'s introspection by reflection capability. Instead of a screen dump of a class's elements, the information is extracted, and then modified to generate a valid XML MOXI file. The MOXI file appears to be a real Mynx class semantically. I've implemented this capability and now can generate a MOXI file for any class in the Java classpath and namespace. For some classes, operator information can be added by hand editing the XML file. So the Java java.lang.String can be modified so that the + plus operator is overloaded for concatenation in Mynx semantics.

MOXI on board-MOXI information inside a Mynx class

One possibility to avoid an external MOXI file or MOXI files in a Myna (Mynx Archive, a ZIP file with Mynx specific information added internally) file is to have the synthesized Java and C# code include a method to read and extract the XML, or even the MOXIObject for the class (such as marshaling and unmarshaling the MOXI information via serialization into an array of bytes). This simplifies things, as the compiler would generate a MOXIObject and then either export and store it to an XML file, or it could be internalized within the synthesized class source as an immutable array of bytes, or immutable MOXI as an XML string.

Similar to Java, external semantics could be checked using the bytecode classfile in Java, or .NET IL assembly for C#. The downside is that the MOXI information could add bulk to the generated binary, and in the code synthesis (the next compiler stage after semantics) require implementing a specific interface.

Later this might be an option for the Mynx compiler, but for now in the implementation an external MOXI file as XML will be utilized. The really deciding factor is that simplicity to get an implementation and working prototype of the Mynx compiler takes precedent--changing the design and implemention should only be done if really necessary or needed--in this case the need is more a variation than rectifying a design flaw or implementation glitch.