Module, Class Name, Namespace, and Type--That is the Semantic Question

In the process of implementing semantic checks within the context of unit (class/program) and methods, I have been trying to organize the semantic checks and actions into discrete phases. It is a process of pushing and poking the operations into some semi-ordered chaos, fleshing out the entire process so that the implementation source code is ready to implement the functionality. I've had to restart (but I did so with the syntax and lexical stages of the compiler, so its a learn by doing, then re-do but with the knowledge gained).

Currently I'm implementing the functionality to read and write MOXI (Mynx Object XML Interface) files--files that contain the semantic information of an external class, such as a method, the parameters, and its mode. Operator overloading of operator and method are also defined. XML is used as a platform neutral means to provide external semantic data. Unlike Java with .class or C# and assemblies which can load the binary class files and by reflection check if a class has a method or attribute, Mynx does not have a platform binary format external object. Reading and writing a MOXIObject to and from an external XML file from MOXIReader, MOXIWriter. MOXI files also will at some future date allow a graphical tool to display class information and namespaces hierarchically. But it is tedious to implement and requires much processing of XML tokens reading or writing from an external file. I've considered a binary format MOBI (Mynx Object Binary Interface) for external semantic class information. But external type information is needed for type compatibility checks, and later in the code generation/synthesis for operators overloaded by class methods. Part of the compilation process is to create a MOXI file for a compiled class for re-use in other Mynx classes or programs.

One complexity is that for a declaration, a type is a type alias, a short identifier for a canonically dotted name the canonical type name.

with mynx.core.*;

class exampleTypes is

    public Int attr to null;  //Int  => mynx.core.Int

    public void exampleMethod is

        var Char chr to null; //Char => mynx.core.Char

    end exampleMethod;

end class;

For the given class, the type alias

Int

or

Char

is used in the declarations of any types in the class. The inclusion statement

with mynx.core.*

acts as the means to include all necessary classes within that namespace by specified with the type alias. It is convenient, both for specifying the namespace to utilize, and in the declaration.

Despite is utility and convenience, there is a design decision--one that must be firmly and clearly stated to avoid any ambiguity in the semantics of Mynx. The design decision can be (excuse the obvious allusion to a popular game show) put in the form of a question. The answer to the question is the resulting choice of design decision.

The question is: "Are Mynx classes unique by the class name or within the namespace--the module and class name?"

For example, the class declared with the type alias of "Int" can exist in multiple namespaces if the class is unique within a namespace, for the module and classes:

1. mynx.core.Int


2. org.apache.mynxtype.Int


3. com.williamgilreath.mynx.numeric.Int

The same class name can be used in different namespaces if the class is unique within the namespace.

Alternatively, a class that must be unique on name only must be unique for any and all possible namespaces. Thus

Int

can be resolved to only one namespace and class, all other classes require a unique name for the class. Thus

Int

is not unique by the namespace, so then the namespaces require unique class names:

1. mynx.core.Int


2. org.apache.mynxtype.Integer


3. com.williamgilreath.mynx.numeric.MathInt

Thus there are two options to the semantics of the type alias and its resolution to the full canonical type name:

1. Class is unique by name alone independent of namespace.


2. Class is unique by name in conjunction with namespace.

Why the incredible concern and focus on what seems a tawdry semantic question of type names?

Simple, if Mynx uses (as was originally but not overtly stated) a class name is unique within its namespace, it is more flexible, but it requires more semantic processing. A type list is created during the initial semantic checks, but for classes unique in a namespace it necessitates a type map, a mapping of the type alias to the canonical type names. Then later, during further semantic phases, the potential canonical type names must be resolved to one specific canonical type name.

If Mynx uses uniqueness on a class name independent of a namespace, the namespace becomes a method of organizing classes, but not in creating a unique type name for a class. The class name is unique independent of namespace, so a specific class can be included by the class name in the declaration and the namespace for the inclusion. Effectively it puts the onus on the Mynx software developer--the user of the language instead of the implementor (me for this compiler).

The unique by class name alone also simplifies the compiler, as it would be a semantic error to have multiple canonical type names for a type alias. If a type alias is not resolved to one, and only one canonical type name it is a fatal semantic error--class inclusion ambiguity (but essentially the same thing unique by class name with namespace allows). The need for a type map would be unnecessary (the type list fully expanded from type alias to canonical type name), as would the resolution of multiple canonical type names for a type alias.

The question stands, the only remaining thing is what approach? That is the question to be considered, along with examining other programming languages including the "Big Three" of C++, Java, and C#. Mynx will be synthesized into code for Java and C#, and potentially C++. In the meantime semantic checks can be implemented up the point of type checks, type annotation, and any other future type-specific semantic handling.