JEX - The Idea

Problem
Solution
Future
References

The objective here is to build a flexible language. One that we, programmers, can extend at will. For example, every time I have to write a 'for' loop like:


	for (Iterator i=list.elements(); i.hasNext();)
	{
		String s = (String)i.next();
		...
	}

I wish I had an additional loop construct that would allow me to write:


	for String s in list.elements()
	{
		...
	}

This version is easier to read (and write), and if the iterator scheme is replaced with an enumeration or an array, this piece of code needn't be changed.

Another example, the getter/setter for class fields. Would'nt you like to write:


	public synchronized get set String name;

instead of the lengthy:


	private String name;
	public synchronized String getName()
	{
		return name;
	}
	public synchronized void setName(String name)
	{
		this.name = name;
	}

I know you can use standard IDE features to write the lengthy version, but how about readability? After all, while debugging, you read a piece of code many more times than you write it. And what if you rename the field, the getter and setter need to be renamed too. Also in this example, the field can be accessed with:


	o.name = "JEX"

instead of:


	o.setName("JEX")

The compiler has enough information about the field to handle the synchronization.

A few years ago, I wrote an EJB code generator based on XML/XSLT. A piece of code was like:


	entity-bean Resource
	{
		Container parent;
		Type type;
		string name;

		finder children(int parentKey) = [parent] = [parentKey];
		finder byName(string text) = upper([name]) like upper('%[text]%');

		public String getIcon()
		{
			return ejb[Type].findByPrimaryKey(getType()).getIcon();
		}
		...
	}
	entity-bean Container extends Resource
	{
		...
	}
	entity-bean Type extends Resource
	{
		...
	}

The code was actually XML, but it is hard to read so I show it in a Java-like form. The various (hard to read and hard to keep synchronized) EJB classes were automatically generated by a relatively simple XSLT transformation, optionally as CMP or BMP entities.

Got the idea: when you give yourself the right language structures, any piece of code you write can be easy to read again and debug and upgrade and, well... you got it.

XML, XML Schema, XSLT are a great combination to define a new extensible language. The mechanism is as follows:

XML	used to write a piece of code (compilation unit, if you will)
XML Schema	used to define the grammar of a language, you can use the import clause to build a language as an extension of another
XSLT	used to, either generate documentation (HTML and/or SVG for UML for example) or generate lower level language code

XML Schema provides a redefinition mechanism that allows to modify a schema construct by extension or reduction. In our first example, the original 'for' loop could be define as:


	element:for
		element:init			; the initialization part
			element:type			; example: Iterator
			element:name			; example: i
			element:expression		; example: list.elements()
		element:test			; the exit test
		element:step			; the step between loops
		element:body

The new construction could be defined as:


	element:for redefines original:for
		reduction:init
		reduction:test
		reduction:step
		extension:item			; the item visited
			element:type			; example: String
			element:name			; example: s
		extension:collection		; example: list.elements()

The transformation (sort of compilation) would be like:


	<xsl:template match="for">
		<o:for>
			<o:init>
				<o:type>Iterator</o:type>
				<o:name>__i</o:name>
				<o:expression><xsl:apply-templates select="collection"/></o:expression>
			</o:init>
			<o:next>
				__i.hasNext()
			</o:next>
			<o:step/>
			<o:body>
				<xsl:apply-templates select="item/type"/><xsl:value select="item/name"/> =
					(<xsl:apply-templates select="item/type"/>) __i.next(); // casting here
				<xsl:apply-templates select="body"/>
			</o:body>
		</o:for>
	</xsl:template>

With 'o' being the namespace of the original language. Yes, this is how easy writing a compiler could be. Of course, XML and XSLT are slow, but if the code is easier to write, bugs will have less room to hide and the loss of time during compilation will be regained during the debugging phase.

Once in a while, language theorists come up with useful techniques like parameterized types, aspects... you name it. Years later, after developping complex compilers, these techniques eventually appear on the mainstream. But then, it is usually a completely new language, and the wheel has to be reinvented again. With the mechanism described above, we have a chance to make any language evolve, one small step at a time. In other words, many small steps instead of a giant's step. The learning curv just got a lot easier to climb.

You think this is a dream, just a dream. Wait until you see the demonstration project: JEX. JEX is a demonstration of the above, available right now. It takes some XML code with Java semantics and compiles it down to the JVM class files. As an example, I have added a simple implementation of the visitor pattern.

JEX is not enough, I want to define a root language that will be as basic as possible. Merely, integer arithmetics, tests, sub-programs, events, threads support and memory allocation. A simple virtual processor. Then, add one layer at a time to reach say, the Java level. Object-orientation, exception handling, parameterized types, etc. All these features can be defined starting with a simpler language.

Each piece of code (call it a compilation unit) can be built on (or refer to) a different language definition (XML Schema). A complete program is built on a set of language semantics. The union of these semantics defines the constraint on the virtual machine(s) needed to run the program. At each branch of the language definition tree, there can be a downloadable optimized version of the virtual machine for any platform.

I haven't been working in IT since I moved back to California, almost two years ago now. So if you want me to continue developping this idea. I'm sure you do. Make it fast, since I am about to start a carpenter career. If I'm not too old yet... Damned!

JEX
Resume (RTF)
Java
JVM
XML
XSLT

JEX - Java Extension

Table of Contents

Problem

Solution

Future

References

Copyright (c) 2002-2003 Patrick Bernard(java2k@sbcglobal.net). All Rights Reserved.