Look within Yourself - Sentence Semantic Checks in Mynx
In Mynx, the parser operates on souce code in the forms of sentence, statement, method, and unit. These four elements are the organizing structures in terms of syntax, and following a syntax-directed approach to semantic checks, a semantic check within each of the organizing structures.
Semantic checks work from the basic element - a sentence, to the more complex - a unit in the form of a class or program.
The interesting observation about sentence semantic checks is that information is unnecessary such as type. The sentence semantic checks are more a structural semantic check within the sentence, without outside information.
For example, the following expression statement sentence is invalid:
What is the type of ‘x’? Is it a class attribute, a method variable, or a method call?
Interesting information, but unnecessary and unneeded. The structure of the sentence by the information within the sentence is semantically invalid. What ‘x’ is does not matter, since the sentence is flawed, determining the nature and type of ‘x’ is irrelevant.
That is the entire notion of semantic checks on sentences - look for errors with minimal information, otherwise an error might be detected much further in the process of semantic analysis - a waste of time and processing.
From the organization of the semantic checks, type checking is the most expensive and final phase of the semantic checks.
The sentence semantic checks also involve collective semantic constraints - semantics taken together. One of which is uniqueness, so that within a higher structure such as a statement, method, or class the sentences are unique.
The difficult part of implementing semantic check is to do so consistently, and to extract the necessary information in each sentence. This can be difficult in some sentences because the sentence contains other syntax objects - and the semantic check implementation avoids any direct coupling. So part of the process is to add query and accessor methods to access information in each syntax object for the semantic check.
After the sentence semantic check is the semantic merge - putting data into a symbol table that is accessed during other semantic checks. The semantic merge enforces the semantic notion of uniqueness - a constraint that certain elements are unique. Class attributes, if semantically valid within a sentence, are merged into the symbol table, so if duplicated is immediately flagged as a semantic error.
Writing the semantic checks involves implementing much of the infrastructure code - the symbol table, the code to access the syntax object information, etc. I thought the parsing phase would be the most difficult, creating syntax objects and then checking them is much more difficult. Never say "It's a snap."
Semantic checks work from the basic element - a sentence, to the more complex - a unit in the form of a class or program.
The interesting observation about sentence semantic checks is that information is unnecessary such as type. The sentence semantic checks are more a structural semantic check within the sentence, without outside information.
For example, the following expression statement sentence is invalid:
this = x;
What is the type of ‘x’? Is it a class attribute, a method variable, or a method call?
Interesting information, but unnecessary and unneeded. The structure of the sentence by the information within the sentence is semantically invalid. What ‘x’ is does not matter, since the sentence is flawed, determining the nature and type of ‘x’ is irrelevant.
That is the entire notion of semantic checks on sentences - look for errors with minimal information, otherwise an error might be detected much further in the process of semantic analysis - a waste of time and processing.
From the organization of the semantic checks, type checking is the most expensive and final phase of the semantic checks.
The sentence semantic checks also involve collective semantic constraints - semantics taken together. One of which is uniqueness, so that within a higher structure such as a statement, method, or class the sentences are unique.
The difficult part of implementing semantic check is to do so consistently, and to extract the necessary information in each sentence. This can be difficult in some sentences because the sentence contains other syntax objects - and the semantic check implementation avoids any direct coupling. So part of the process is to add query and accessor methods to access information in each syntax object for the semantic check.
After the sentence semantic check is the semantic merge - putting data into a symbol table that is accessed during other semantic checks. The semantic merge enforces the semantic notion of uniqueness - a constraint that certain elements are unique. Class attributes, if semantically valid within a sentence, are merged into the symbol table, so if duplicated is immediately flagged as a semantic error.
Writing the semantic checks involves implementing much of the infrastructure code - the symbol table, the code to access the syntax object information, etc. I thought the parsing phase would be the most difficult, creating syntax objects and then checking them is much more difficult. Never say "It's a snap."
Labels: semantic analysis, semantics, sentence semantics, symbol table

<< Home