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.