Got MOXI, What's Next: In Betwixt and Between the Second Compiler Phase
After implementing the necessary MOXI functionality to read, write, and create instances of a MOXI object for the next or second compiler stage of phase -- TEAC (type existence, annotation, compatibility). But between the first and second stages of the compiler is an intermediate step to translate types into full type names, the pre-stage of type existence analysis.
The principle of type necessity; which is the principle of if a type is not found, why bother to check existence internally (declaration before use in method, or declaration of attribute) and then annotate and type check? Fatal error of semantics, like a fatal error in scanning, partitioning, or parsing--lexeme/sentence/syntax is flawed so can't continue to compile.
A point is the distinction between resolution or resolving a class or type and checking external existence. Resolution is creating the full name such as
For classes that are included with the absolute namespace, the process is simply to see if within the search path of the compiler for MOXI files (i.e. the MOXI path) the files exist, and then are read as a MOXIObject. The internal compiler structure that holds an instantiated MOXIObject is (quite obviously...) a moxiMap.
Relative namespaces must be resolved, that is, the short type or class name such as Int, Ordinal, Real, or String, must be appended to relative namespace inclusions such as mynx.core.* or mynx.trove.* so resolution is to find the full namespace such as mynx.core.Int for the short type alias of Int.
Naturally, the check is to see if a MOXI file exists. Remember order of declaration determines which namespace is used, and a class name is unique within the unit, hence a short class name like Int is resolved to one full namespace in the order the relative namespaces are declared. Hence there is no mynx.core.Int and mynx.type.Int, the class is unique thus there cannot be two inclusions from resolution. First come, first resolution.
Again, like absolute namespaces, a MOXIObject is instantiated and stored in moxiMap.
Should at least one of the MOXIObject is not be found, or an if an error occurs while instantiating (or marshaling from XML to an instance object within the compiler) a MOXIObject, the semantic error is a fatal one...the compiler will continue to try and instantiate other MOXIObjects, but will not proceed in the semantic checks or further compilation process. The error is fatal, a specific class type could not be found, so the process cannot continue without the semantic information in the MOXI file.
An interesting and unexpected complication is the implementation of the base functionality for the checking and resolving of a namespace. The complication is accessing the external environment--specifically the compiler can potentially couple, or have a strong coupling, to the runtime environment or platform.
A compiler book (and an excellent one at that...) "Compiler Construction: A Recursive Descent Model" by John Elder 1994 actually in the implementation of the programming language Model examines this possibility. The author (p. 37, Chapter 4.4) puts it, "...an interface to these facilities of the compiler's environment."
Realizing the approach to the problem of non-coupled access to the platform, now the question is the approach, such as interface/class, a singleton class, etc.
Another design consideration is the namespace to place the Host class in--such as
The decision is two-fold and simple. Use a specific semantics host class for semantic access, and keep it in the
In finding the MOXI files to determine if a particular one exists, the compiler must know where to look--a MOXI path parameter. Use the MOXI path parameter to search for MOXI classes, where MYNA files (Mynx Archive) found. How the MOXI path parameter is provided (command-line parameter, configuration file) is irrelevant as how it is accessed--through the hosting class.
Need and Necessity for Type Existence Analysis
The principle of type necessity; which is the principle of if a type is not found, why bother to check existence internally (declaration before use in method, or declaration of attribute) and then annotate and type check? Fatal error of semantics, like a fatal error in scanning, partitioning, or parsing--lexeme/sentence/syntax is flawed so can't continue to compile.
Type Existence Analysis the Pre-TEAC Step
- Check existence and create moxiMap of MOXIObject for absolute namespace types
- Resolve existence and create moxiMap of MOXIObject for relative namespace types
A point is the distinction between resolution or resolving a class or type and checking external existence. Resolution is creating the full name such as
mynx.core.Integer, finding a class or type in the full name. Checking is that for a full name, that the class or type exists as an external MOXI file. Resolution is both creating the full name, and checking for the existence of a MOXI file, whereas checking avoids the full name creation process. Absolute Namespace Type Checking
For classes that are included with the absolute namespace, the process is simply to see if within the search path of the compiler for MOXI files (i.e. the MOXI path) the files exist, and then are read as a MOXIObject. The internal compiler structure that holds an instantiated MOXIObject is (quite obviously...) a moxiMap.
Relative Namespace Type Resolution
Relative namespaces must be resolved, that is, the short type or class name such as Int, Ordinal, Real, or String, must be appended to relative namespace inclusions such as mynx.core.* or mynx.trove.* so resolution is to find the full namespace such as mynx.core.Int for the short type alias of Int.
Naturally, the check is to see if a MOXI file exists. Remember order of declaration determines which namespace is used, and a class name is unique within the unit, hence a short class name like Int is resolved to one full namespace in the order the relative namespaces are declared. Hence there is no mynx.core.Int and mynx.type.Int, the class is unique thus there cannot be two inclusions from resolution. First come, first resolution.
Again, like absolute namespaces, a MOXIObject is instantiated and stored in moxiMap.
No MOXI, No Problem--No Compilation
Should at least one of the MOXIObject is not be found, or an if an error occurs while instantiating (or marshaling from XML to an instance object within the compiler) a MOXIObject, the semantic error is a fatal one...the compiler will continue to try and instantiate other MOXIObjects, but will not proceed in the semantic checks or further compilation process. The error is fatal, a specific class type could not be found, so the process cannot continue without the semantic information in the MOXI file.
Compiler Interface to External Environment
An interesting and unexpected complication is the implementation of the base functionality for the checking and resolving of a namespace. The complication is accessing the external environment--specifically the compiler can potentially couple, or have a strong coupling, to the runtime environment or platform.
Host from Modula-2
A compiler book (and an excellent one at that...) "Compiler Construction: A Recursive Descent Model" by John Elder 1994 actually in the implementation of the programming language Model examines this possibility. The author (p. 37, Chapter 4.4) puts it, "...an interface to these facilities of the compiler's environment."
Realizing the approach to the problem of non-coupled access to the platform, now the question is the approach, such as interface/class, a singleton class, etc.
Namespace, Where Art Thou Class?
Another design consideration is the namespace to place the Host class in--such as
proxima.semantic or proxima.compiler, etcetera. Since the Host class allows platform independent access to the resources of the environment it is not necessarily specific to semantic analysis. Thus the namespace to place and organize the Host class is a concern for future compiler design and development. The decision is two-fold and simple. Use a specific semantics host class for semantic access, and keep it in the
proxima.semantic namespace. The class is named possibly moxiHost or hostMOXI or perhaps ExternMOXI.MOXI Path Parameter
In finding the MOXI files to determine if a particular one exists, the compiler must know where to look--a MOXI path parameter. Use the MOXI path parameter to search for MOXI classes, where MYNA files (Mynx Archive) found. How the MOXI path parameter is provided (command-line parameter, configuration file) is irrelevant as how it is accessed--through the hosting class.
Labels: existence semantics, moxi, Mynx compiler, mynx semantic
posted by Will Gilreath at
8:49 AM
