Uniqueness in Method a Sanity Semantic Check for a Unit Method

In uniqueness context semantic checks, originally declarations within the semantic context of a method were not checked to be unique. The existence checks were originally thought to be completed, but then I realized for a method the internal declarations require a uniqueness check.

A Premise of Semantics

The premise is that of fatal semantic error terminating compilation, find ambiguity in non-uniqueness within a method, compiler bails out. To put it more colloquially, if the Mynx source code has a defect, the compiler must reject; if the Mynx code does not semantically fit, the compiler must acquit...err, quit. This avoids wasted effort and compiler cycles only later to detect an error that terminates compilation. Better sooner rather than later to stop compiling.

Concept - What a Concept

From the premise to the concept is simple enough, check within a class or program method if local declarations are unique in context. Enforce a local uniqueness semantic constraint, using a temporary symbol map.

class Exemplar is

    public methodDeclCheck is
        
        var Int x to default;

        var Ord y to null;
        
        //semantic method context error: 
        //variable 'x' not unique in method
        var Str x to default; 

    end methodDeclCheck

end class;

From Idea to Implementation in Context

The implementation uses the Context object, create a temporary symbol map, and long term type table to gather types used in declarations within a method. A method can be a method, constructor, or a destructor. The temporary symbol map is transitory, it is created at the start of a method, and disposed of at the end of a method. As Mynx does not allow nesting of methods (method scope is explicit in the method header, not implicit in nesting within another method) it is a simple start the symbol map, add a declaration to see if it is already declared, and close the symbol map. Variables declared in a method header are the first added to the symbol map, declared and initialized with a method invocation.

class methodSymbolMap is
    
 public construct is           //=>Context start symbol map
        
  var myType to null;          //=>Context check declaration unique

 end construct;                //=>Context close symbol map

 
 public void doIt(in Int i) is //=>Context start symbol map
        
  var Ordinal j to null;       //=>Context check unique in method

 end doIt;                     //=>Context close symbol map

     
 public void doIt is           //=>Context start symbol map        
  to doIt(0);                  //=>Context close symbol map

     
 public peerless is            //=>Context start symbol map
    implied;                   //=>Context close symbol map

end class;

For a class method, there are some variations--an implied method, and a method equivalent. In either case, the symbol map is disposed of, as there is no method body for declarations. The type map stores all types or classes used, including those within method declarations.

And After Uniqueness in Method

After the first pass and uniqueness constraint check of class or program elements, and declarations within a method are unique, the next state is type existence, annotation, compatibility (TEAC). But if there are no semantic errors in the first stage, the compiler is assured that internally types are unique and not replicated, so can check existence semantics without any variations or complications relating to uniqueness in context.

The declarations within a method are unique, so the existence checks only focus on existence externally and then internally. And if not, then the semantic error is a fatal one, thus the compiler would terminate compilation before proceeding to the next phase.

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.