In Every Program Lurks an Inner Class

Zepton is designed to be compatible with and up to the syntax of Java 1.5--Java Tiger. One reason is to keep it simple, and using the latest and greatest Java syntax is complex. Also Zepton’s target user--a learner and a person desiring a quick-and-dirty program--neither wants the Java sophistication.

But one Java feature Zepton supports is an inner class. I often find myself thinking of a C struct, Pascal record, but the inner class is much more. But there is a possible conundrum with an inner class:

prog innerClassProg {

  class Inner extends innerClassProg {
    //inner class body
  }

do
  //program block
}

The problem is one of conceptual semantics--a Zepton prog is a unit of application, execution--a program, not a class. So an inner class sub-classing a program is a semantic error.

Yet when transcompiled into the Java source code:

public final class innerClassProg {

  private innerClassProg{}

  class Inner extends innerClassProg {
    //inner class body
  }

  public final static void main(final String[] args){
    //program block
  }

}

This is valid Java code for transcompilation, but invalid Zepton code--a program is not a class.

An example of how a programming language compiler, even with transcompilation to a compatible programming language, must enforce the conceptual semantics of a programming language.

Zepton is simple because it does not re-create many things that Java has--one is inner classes. But the simplest change from class entity to program entity can have a subtle but significant impact on semantics and compilation.

The solution to this quandary is simple--do not compile, it is a semantic error even if the transcompiled code is valid. More simply Zepton is Java but Zepton is not Java.

The "main" Question...a Question of Ambiguity in Language Design

A design question in Zepton is when a user defines a method "static void main(String[] args)" which in Java is the main method. The problem is Zepton uses a do-block as the implicit main method, or the program body.

So the question is how to handle this ambiguity? Which is the progam main method, and if a user writes it, how does the compiler handle it? There is a main method, which in Java is where execution begins, and the program do-block, which is where execution begins in Zepton.

Example "helloWorld.zep" code:

package zepton.demo;

prog helloWorld {

  static void main(String[] args){

    println("Hello World!!!");
    exit(0);
  }

do

  println("Hello World!!!");
  exit(0);

}

This is an example of Java semantics and syntax versus Zepton semantics and syntax. But a concern is the cognitive dissonance caused when "main" is used in Java, versus how it is handled in Zepton.

Moving Upward in Java Syntax--Having a Tiger by the Tail

ZeptoN is intentionally designed to be fully compatible with Java syntax--but eliminating the class constructor and some other features...like constructors, modifiers for access, extends and implements. This is from the addition of the “prog” or program construct.

Originally I opted for the Java 1.1 syntax, and then was incorporating later features--such as enums, static import, and so on. But then in going through the syntax of Java, I realized it would be easier to user a later, more sophisticated Java syntax, and remove features from syntax.

I opted for the Java 1.5 syntax, Java “Tiger” because it has features I want included in Zepton...such as inner classes, enumerations, static imports. One feature I have removed is annotations--that’s for a more savvy, sophisticated user, and when constructing classes for re-usable functionality.

Zepton is for those learning to program and for those that want to quickly codify a solution to a problem using Java style syntax and concepts. The appeal is on both ends of the software development continuum--new users moving along the continuum, and for advanced users that need a method to write a program quickly using Java.

That is one major design flaw of Java--the lack of a simple program construct. This is almost Pascal in reverse, Pascal had a great program construct, but then was weak in providing a mechanism for reuse and libraries without extending the language in a non-standard, proprietary way--such as Turbo Pascal.

The difficulty is with Java features for classes, some are easy to remove--such as generics (no need for generics in a program) whereas others can require some thought (annotations are great, but for the two kinds of users not really relevant), but others can be useful such as inner classes, enumerations.

For a static block, that’s a more complex question, since a program is not a class so not loaded unless re-run. A static block is a means to ensure initialization and default behavior before a constructor is called to create an instance--but there are no instances and no constructor calls since the program is not a class.