How Do You Do It? Zep To It! ZeptoN “Echo” Transcompiler is Out There.

I have released the ZeptoN transcompiler on my GitHub repo at https://github.com/wgilreath/ZeptoN. 

This is version 1.0.1 as a few glitches were fixed. The transcompiler compiles into Java source code, and then uses the backend Java Compiler API to produce a Java .class file that can execute on JDK 11 and greater. A pre-built JAR file is ready to run. The entire software collection and some ZeptoN “zep” source code files are released under GPL v. 3.0.

I’m currently working on a short whitepaper, which I will publish and release sometime soon. ZeptoN is Java syntax but without object-oriented overhead. I was tinkering with multi-threading, but simpler.

I’d love to have contributors to the project!

ZeptoN Echo Compiler

ZeptoN Echo Compiler July 19, 2019

Eureka and shiver my timbers! I have implemented a working prototype compiler for ZeptoN. This compiler I call the "echo" class compiler. The compiler is a transcompiler, no lexer, parser. The transcompiler compiles the ZeptoN source code into Java source code.

Echo...Echo...Echo

The "echo" is that, except for the ZeptoN keywords, all source code is "echoed" into the Java source code that is compiled.

The source to bytecode binary uses the Java Compiler API. I originally developed a simpler Java compiler "WEJAC" that I revamped into an in-memory compiler "WEIMJAC" that uses a Java source code object.

I then used the "WEIMJAC" compiler to implement the ZeptoN compiler--"zep" for the file extension ".zep" used for ZeptoN source code. The only difficulty was to create a method "transcompile()" to transform the ZeptoN source code into Java code.

The Challenge of Error Integrity

The challenge was to maintain the line numbers so that an errors reported actually show the ZeptoN source line, and code fragment.

Originally I "chomped" (to use a PERL term) the comments and whitespaces...but it obfuscated the line numbers for error messages.

The Main Challenge

One difficulty is if a "static void main" method is used. Since the block of code from "begin" to the closing brace is transcompiled into a "main" method, a duplicate main method is problematic.

A friend suggested a colorful error message:

    static void main
    ^^^---------------- We don't allow this here!
   
But, that is not very helpful. A newbie must not use a specific method without knowing why it is an error. Also a "main" method might be useful when writing a ZeptoN program.

The solution is to "mangle" a "main" method into a valid identifier, and any references to the existing main method before the auto-generated main method is created.

Compiler Options

Since the ZeptoN echo compiler is built upon the WEJAC compiler, it has the same options (I'm considering adding some more...) which means few. WEJAC was designed for simplicity, so the ZeptoN compiler also has fewer options.

Example ZeptoN Program

This 20-line ZeptoN program grabs a web page, and then dumps it to the screen, console, or terminal.

/*
ZeptoN Compiler Options: [-g] Files: [FetchURL.zep] Encoding: UTF-8

Time: 614-ms for: FetchURL.zep
ZeptoN Compiler result for file: 'FetchURL.zep' is: Success.

ZepC]$ls -l FetchURL.*
-rw-r--r--  1 williamgilreath  staff  9875 Jul 17 06:12 FetchURL.class
-rwxr-xr-x@ 1 williamgilreath  staff   706 Jul 17 06:13 FetchURL.zep
*/
prog FetchURL{
begin
    StringBuilder content = new StringBuilder();
   
    URL url = new URL("https://wgilreath.github.io/WillHome.html");
    URLConnection urlConnection = url.openConnection();

    BufferedReader bufferedReader = new BufferedReader(
        new InputStreamReader(urlConnection.getInputStream()));
    String line = EMPTY_STRING;

    while ((line = bufferedReader.readLine()) != null){
        content.append(line + "\n");
    }//end while
    bufferedReader.close();
   
    println(content.toString());
    exit(0);
}//end prog FetchURL

The multi-line header comments show the output of the command given. The command is:

[ZepC]$zep -echo -time FetchURL.zep

The ZeptoN Echo compiler echoes the parameters given, and times the compilation for the ZeptoN program FetchURL.zep

Going Forward

I intend to open-source and release the source code for the ZeptoN transcompiler on GitHub.

If interested, e-mail if you want to contribute and/or participate. The more the merrier!

To Begin, Do a Change in Keywords for ZeptoN

The original goal I had in mind was to only introduce one new keyword into ZeptoN, and the rest is Java-centric syntax. The problem is that ‘do’ creates some processing problems with the transcompiler.

I considered something that is a mix of Java features like ‘do:’ which is more Pythonic, but in Java is a keyword used as a label. The problem is that it introduces a feature--a label, that is also a keyword, which is illegal in Java. 

I could by fiat make it legal in ZeptoN, but then it has to be unlearned when doing Java, or if a newbie moves up to Java.

Ultimately I opted to go Ruby-ish at the suggestion of a friend, but I’m old-school so it seems more Algol-ish...from the realm of Pascal and Ada95. The keyword change is to the ‘begin’ keyword.

Thus HelloWorld.zep becomes:

prog HelloWorld {

begin

println(“Hello World!!!”);

}

Java is verbose (actually a big help when debugging, or working on legacy source code), so another wordy keyword is not so much a problem. The trade-off is that while it simplifies the transcompiler, it does add another non-Java keyword.

So now ZeptoN has two keywords:

1. prog - start of the program structure
2. begin - entry-point of the program structure

I also considered “main” or “main:” since it would be a legitimate label in Java. The problem again is it takes “main” which is not a keyword, or label, respectively, and makes it once. So a user must be mindful of that fact.

Thus easier to use ‘begin’ which is not a Java keyword, and stands out in ZeptoN source code. So to allude to Lewis Carroll’s Alice in Wonderland:

“Begin at the beginning," the King said, very gravely, "and go on till you come to the end: then stop.”

Perhaps Lewis Carroll is among the first programmers like Augusta Ada King, Countess of Lovelace, albeit indirectly like a double C pointer **ptr.

Zepton is 21st Century Pascal??

I had someone tell me when I explained Zepton...actually ZeptoN, to them tell me in so many words that Zepton is like Pascal...the popular language from the 1970’s created by Niklaus Wirth.

My own process of learning to program was BASIC (of course...all kinds from Sinclair BASIC in 1978 to GW-BASIC in 1985 to QBASIC and QuickBASIC in 1990), FORTRAN77, Pascal and C, C++, and Java. Along the way other programming languages I’ve learned...Forth, Prolog, LISP, Scheme, etc. But Pascal was a favorite. Back in the 1990’s I was a computer science major, and then later the department moved to C++, but code was the Borland Turbo Pascal, and of course Sun Pascal (64-bit). One language I liked but Veridian Ada95, I was a big Ada fan...it was verbose, but very portable. Later I was a fan of C#...but I preferred the Mono mcs C# compiler.

But Java has filled that role of Pascal, but Java is a cool programming language (everyone seems to hate it...), but it is vast in features and concepts to learn. So hence Zepton.

Unlike Pascal, Zepton is compatible with Java syntax, and uses Java class/libraries/packages. So very much a learning language.

Yet I think this someone was trying to imply ZeptoN was a “toy language” good for learning, but not much else. Even if this were true, Zepton allows a newbie to learn Java without having to learn features for classes, interfaces, etc. So that knowledge is scalable and applicable to Java.

But I think learning language, or a “toy language” and a programming language for development is a false alternative, a false choice. I remember a favorite computer games, “Secret of the Silver Blades” and “Pool of Radiance” were written in Turbo Pascal. So much for a “toy language” but Turbo Pascal added features not standard to Pascal to give it more power, usefulness, utility. Java has such features in the libraries/packages/frameworks, Zepton allows a developer to use them without creating a class.

Consider the ubiquitous program in both Java and Zepton--Java first:

public final class helloWorld extends Object {

  private helloWorld(){}

  private final static String GREETING = “Hello, World!!!”;

  public final static void main(final String[] args){
    System.out.println(helloWorld.GREETING);
    System.exit(0);
  }
}

similarly in ZeptoN:

prog helloWorld {
  final static String GREETING = “Hello, World!!!”;
do
  println(helloWorld.GREETING);
  exit(0);
}

Quite simply, the ZeptoN program is more concise, and implements a similar application.

One possibility is to use an existing but unused keyword from Java, or even another to shorten “final static” to say “const”...but that would create a ZeptoN feature that is not conceptually and syntactically compatible with Java. That would contradict the core idea that ZeptoN is Java compatible in syntax, keywords for features used. Also I don’t measure the versatility of a programming language with using fewer keywords, operators, or other lexemes.

APL is great example of a programming language that is concise, easy to write--but a write-only programming language. Another possibility is to allow more concise syntax, and as part of the transcompilation process, emit “pure” ZeptoN source code as part of the transcompilation process. Still, a newbie or developer would then have to unlearn the concise syntax not available in Java and make the distinction in ZeptoN. So not a useful approach or option.

So ZeptoN might be considered a “21st century Pascal” but its more like the more powerful Pascal dialects but without an proprietary, idiosyncratic features required with the original Pascal. Also ZeptoN is not a new, untested, untried programming language, its is Java with a program entity sans more advanced object-oriented features.

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.