Friday, August 16, 2019

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!

Friday, July 19, 2019

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!











Friday, June 21, 2019

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.

Tuesday, April 16, 2019

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.


Wednesday, March 27, 2019

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.

Monday, March 11, 2019

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.

Monday, March 4, 2019

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.

Sunday, February 24, 2019

Java In and Out Parameter Passing

The Zepton programming language implicit uses a core language class Zepton.java to provide auto-magically to software developers. My original goal was to implement a method readln() that takes various primitives--Boolean, Integer, Long, Double, Float, String, char--and return the value read on a line into the parameter variable.

But a glitch--the way Java handles parameters. Primitives, even the object wrappers (from int to Integer, double to Double, etc.) are passed as parameter for output, not for input and output.

In doing some more research, I found that in the Java Language Specification, Java uses a simple parameter passing method called “pass by value.”

The Java Language Specification (Section 4.3) declares that the passing of all datum, both object and primitive data, is defined by the following rule: “All data is passed by value.”

For a primitive--int, Boolean, Integer, Double, is passed by value--the value of the primitive. For an object like ArrayList, HashMap, int[] (yes, arrays are an object, even arrays of primitives), the reference--the address to the pointer, is passed by value--the address of the object in memory.

So a general-purpose readln (or readLine) method that takes an object and can return a value through the parameter is...difficult to implement, and would require some “extensions” to Java. I have done so with a programming language I created--Boz that was transcompiled to both Java and C#.

A great online article  “Passing by Value vs. Passing by Reference in Java” by Justin Albano examines these issues.

But, Zepton is designed to only add “prog” or a program structure to the Java language, not modify or extend it into a new programming language. The strength (and in this case a weakness) is to be fully syntax and conceptually compatible with Java.

A Zepton developer moving to Java will experience a cognitive shock--or cognitive dissonance if the readln() method takes a parameter and returns it as output--vanilla Java does not--so a “bump” in the conceptual road.

Thus Zepton must be compatible, no surprises. The core language class Zepton.java will use the same method signatures from Runtime.java, System.java, PrintStream.java, and DataInputStream.java.

For input and output the methods in Zepton are:

class Zepton {

  public static printf(Locale, String, Object...);

  public static println(String);

  public static println(Integer);
  public static println(int);

  public static println(Double);
  public static println(double);

  //...println methods for the various primitives and object wrappers

  //...read line methods for various primities and object wrappers
  public static String readLine();
  public static int readInt();
  public static double readDouble();
  public static boolean readBoolean();

  //...other methods used by Runtime, System
  public static void gc();

  public static void exit(int);

}//end class Zepton

As a software developer, compiler writer, programming language designer, I want to add and improve methods. For example I want to modify the gc() method to return a long--the amount of bytes of memory after running garbage collection on the Java runtime environment.

But Zepton is about Java likeness...so modifying a commonly used method like gc() would create cognitive dissonance.

One possibility is to rename and create a method that does the garbage collection with the feature of returning the long amount of bytes of memory recovered--but then when a user moves to Java, well “shiver my timbers” the equivalent method in Java doesn’t have that feature.

Thus Zepton is so simple--Java compatible, adding the program construct, removing features (a program does not have a constructor or destructor...) but remaining conceptually and syntactically similar to Java. The core language Zepton.java simply is the intersection of methods and constants from the various classes in Java for the Zepton programming environment.

So the Zepton program:

package zepton.demo;

prog helloWorld {
do

  println(“Hello world!!!%n”);

  exit(0);

}//end prog helloWorld

If the same program used the Java environment explicitly:

package zepton.demo;

import java.lang.Runtime; //or import java.lang.*; which is implicitly included
import java.lang.System;

prog helloWorld {
do

  System.out.println(“Hello world!!!%n”);

  Runtime.getRuntime().exit(0); //or System.exit(0);

}//end prog helloWorld

But, Zepton is meant for learning to program in the Java environment, or for quick programming...so all the explicit overhead is overwhelming and overloading.

Thus keep it simple...silly, and for parameter passing, extending or adding methods that are enhanced...keep it simple...so this too shall pass...and not as a parameter.


Tuesday, February 19, 2019

The Zepton Class for Core Functionality


For the Zepton programming language, I am trying to develop a "core" class of functionality that is static attributes an methods that are implicitly included with a static import into the generated Java code for a Zepton program. This core class is Zepton.java, and will be a nexus of input, output, utility, and other functionality that is available in multiple Java classes--but is implicit for a Zepton program.

More specifically with an example:

package zepton.demo;

prog helloWorldUserName {
do
  println("Hello World!!!");
  println();

  print("What is your name?->");
  String userName = readln();
  printf("Hello: %s %n", userName);

  exit(0);
}

When transcompiled into Java code the result is the Java class:

package zepton.demo;

import static zepton.lang.Zepton;

public final class helloWorldUserName extends Object {

  private helloWorldUserName(){}

  public final static void main(final String[] args){

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

    print("What is your name?->");
    String userName = readln();
    printf("Hello: %s %n", userName);

    exit(0);
  }

}

Users learning to program on the Java platform using Zepton do not need to focus on peripheral details that a full Java class will entail, nor need focus on the details of such classes as java.lang.Runtime, java.lang.System, etc. The implicit static import is "auto-magically" generated by the transcompiler.

So, the problem and issues are around the "core" Zepton class with the implicit functionality. But in writing the core functionality, I'm running into some issues with the Java programming language--going back to the fundamentals has revealed some fundamental glitches or design flaws in Java.

The strength of the Zepton programming language is it is an extension of Java, with a program structure and concept. But this is also the weakness...adding a cool new feature is possible, but it will be Zepton-centric and the user will have to "unlearn" this feature...and the two groups of users are learning Java but don't want to drown in the Java vastness, and a user that wants a quick-and-dirty program without all the Java trimmings and accoutrements.

So for the core Zepton.java class, I am avoiding extending Java with Zeptonic-only features, but still want the core Zepton feature class--competing requirements for something so foundational--more on this as I codify.

Saturday, February 16, 2019

Introducing the Zepton Programming Language

The Zepton programming language is a Java syntax compatible programming language that has only a “program” construct. Zepton is from “zepto” the smallest measurable interval of time, so small, and the letter “N” for the Nth programming language--”zepto” + “N” or “Zepton” programming language.

Zepton is designed with only one new keyword: “prog” for a program. Java is object-oriented centric, which means everything is a class and that a class has to offer.

While Java is a very popular programming language, and is used to teach programming and software development, it has become a gargantuan programming language with the many features.

Zepton is intended for learning the syntax, statements, and concepts of Java--while being able to use all existing Java classes, libraries, packages, and frameworks. Also Zepton is useful for quick and dirty programming--without having to create an entire class.

The required, classic example is in Zepton:

package zepton.demo;

prog helloWorld {
do
  println(“Hello World!!!”);
  exit(0);
}

The equivalent Java verbose class is:

package zepton.demo;

import static java.lang.System;

public final class helloWorld extends Object {

  private helloWorld(){}

  public final static void main(final String[] args){
    out.println(“Hello World!!!”);
    exit(0);
  }
}

Zepton allows a program to be written to implement functionality, but without the need for object-oriented features of code re-use. But Java code can be re-used in a Zepton program.

Zepton is not “Yet Another Programming Language” (YAPL) but a conceptual extension of the Java programming language--which has class, thread, enum, now outside an outside programming language that builds on Java with the program concept.