Mynx Context Semantic Constraints on Scope and Uniqueness

In implementing the sentence semantic checks, part of the semantic processing is to verify context of syntax elements. The two primary context semantic constraints that must be verified are:

1. unique - syntax element is not duplicate or replicated - that creates an ambiguity.


2. scope - visibility of a syntax element for use within statement, method, or unit.

Unique

Uniqueness is not unexpected, but the question in semantic processing of a syntax element is “Unique on what lexical element?” For example, a class attribute is unique on the attribute identifier, but a class overload is unique on the operator.

1. class attribute/program attribute - unique on attribute identifier.


2. class overload - unique on operator used in overload.


3. class method/program method - unique on method identifier and/or method parameters. For covariant method, unique on method return type identifier.


4. class obviate - method identifier and/or method parameters.


5. class constructor - unique on parameters.

Scope

Scope is the visibility of syntax elements within the class. Mynx uses an explicit scope control by name, not syntax position or nesting like other languages.

Mynx has two scopes:

1. Global - complete visibility within the unit, or class/program; A global syntax element does not necessarily have to be declared before use. Order of declaration is immaterial.




class doScope is

   public construct is to null;

   public void doSomething is

      var Int myInt to 1;

      myInt is this`INT + 2; //use class attribute although declared afterward

   end doSomething;

   private constant Int INT to 0;

end class;




2. Local - visiblity within a method, constructor, destructor, loosely “a method” in terms of syntax; and declaration must precede use.

Within a Mynx method, declaration is required before use, but there is no block-nesting of scope. So a declaration within a try-statement is not limited to the block-scope of the try-statement, the declaration is visible to all statements following the declaration.

public void doMethod is

    try
        Int x to 0;
        ... rest of statements...
    when(Trap)
        ... do something ...
    end try;

    x++; //x is visible throughout the method not just within try-block

end doMethod;

The big difference in scope between global and local scope is global has visiblity within the block - the unit. Local scope has visibility after the point of declaration.

For global scope, visibility everywhere allows declarations to be clustered logically together. For a method, a variable needs to be declared before use, but is visible from then onward, so do not have to worry about nesting scope within a statement. Both are flexible, allowing the software developer choice.
A unit (class or program) element is useable by all other unit elements. A trade-off is that some elements such as attributes or methods can be scoped in or out by name - made opaque or invisible but without nesting the declarations.

A feature from Pascal that is mentioned in Kernighan’s “Why Pascal Is Not My Favorite Programming Language” is the inverted pyramid of declarations. This is helpful to the compiler writer for a one pass compiler, but a royal pain for the developer. The emphasis of Mynx is to give a developer or user choice, and not foist any particular approach.

Declaration before use in a method but visible throughout the method is a trade-off. As a method is the core of making a class function, using variables without declaring them first is very flexible, but is not type-safe at compile time.

In short, as Mynx is a strongly typed programming language, types must be checked at compile time, so declaration before use facilitates it. And, using a variable then declaring it afterward is counter-intuitive. I’ll avoid digression into dynamically typed languages or dynamic variable languages; but dynamic typing and useage is powerful for a language that needs those features as part of the language rationale.

The visibility afterward for all within a method is to avoid frustration of scoping within multiline statements, something that drives me nuts in C++ and Java. Especially when I’m adding code and the variable is not visible outside the scope of a try-statement or loop statement.

The rules for scope and uniqueness are needed to implement the semantic checks, but the rules are from the rationale - the how’s and why’s of the Mynx language. Some are for compiler design and development, others are from my own experience as a software developer. Implementing the semantic checks has forced me to look at Mynx and ask the universal question of “why?” -- something a language user often does not but accepts as “the way it is.” Now as a language designer, I am sitting on the opposite side of the programming language table, and it would be accepting the way it is to use existing language uniqueness and scope rules. Mynx is not to be another Java/C++/C# clone.