Mynx Type and Casts in the Design of a Language

In the October revision of The Mynx Programming Language Manual (TMPLM), one important clarification and specification is the rules for types and type casting. Before, the general rule is strong typing, but in compiler implementation, it requires more specific explanation.

Language Complexity

Other programming languages (such as the synthesized into programming languages of Java and C#) can have very labyrinthine type rules. The complexity stems from the programming language having many different entities--such as Java having primitive types, classes, and interfaces, or C# with struct, class, and interface.

Mynx has only one reusable entity that has type--a class. Programs are never reused, so have no type rules to use them. There are no other entities, and in Mynx class is type (a point that creates much religious-level conflict in programming language theory), class and type are synonymous.

Mynx only has references to instances, no primitives or pointers. Again, only one conceptual entity, one thing. One software entity--class, and one kind of runtime entity--a reference.

Mynx is strongly typed, so the overall guiding principle or rule is like is compatible only with like. General rule of strong typing -- for two references (identifiers or literals) both must be of the same type, i.e. type compatible.

Mynx has only three rules for type and casting. All are in some ways common sense, but must be formalized.

Type Span

A type can only be cast to an immediate super-class. In effect an upward cast can only be to a super-class inherited by the base class.

Type Intent

A type can only be intentionally or explicitly type cast, never implicitly. There is no implicit upcast to a super-class.

Type Limit

A type that has been cast upward can be re-cast downward to the base class, but never to a sub-class derived from the base class.

Type and Casting Rules Synopsis

1. Type Span - Cast upward to immediate super-class type not further up the hierarchy.


2. Type Intent - Cast to alternate class type is explicit, not implicit.


3. Type Limit - Cast to own type or super-type; but not to sub-class types.

A Note on Operator Overloading and Methods

The rules for Mynx cast and type apply to Mynx classes. However, it does not mean the following code fragment is type invalid:

    Int i to 0;
    Real r to null;

    r as Real(0);
 
    r = r + i; //type incompatible??

Remember though, that a class can have a method to take any type and operators can be overloaded.

Rewriting the Mynx source code with the explicit method calls instead of the operators:

    Int i to 0;
    Real r to null;

    r as Real(0);
 
    r.set(r.add(i)); //type incompatible -- no!

Providing the class Real.mynx has a method: add(Int) that returns a type Real, type compatibility is valid. The method set(Real) assigns a type Real instance to the variable identifier.

I Think, Therefore I Code

The software developer--the class designer must design a class to mix and match the variety of types a class can work with, and the operator overloads to associate a method with operator. For a class designer, the immediate super-classes (including virtual classes) will impact the ability of a software developer using the class to type cast to those classes.

In short, object-oriented software design in Mynx requires thinking unfortunately it seems much software is ad hoc, designed for the immediate need, but then grandfathered into the future, and other software developers are stuck with it.