Interpreter « Development « Java Articles

GNU EMACS Before HotJava arrived, perhaps the most successful application with dynamic execution was GNU EMACS. This editor's LISP-like macro language has become a staple for many programmers. Briefly, the EMACS LISP environment consists of a LISP interpreter and many editing-type functions that can be used to compose the most complex macros. It should not be considered surprising that the EMACS editor originally was written in macros designed for an editor called TECO. Thus, the availability of a rich (if unreadable) macro language in TECO allowed an entirely new editor to be constructed. Today, GNU EMACS is the base editor, and entire games have been written in nothing more than the EMACS LISP code, known as el-code. This configuration ability has made GNU EMACS a mainstay editor, while the VT-100 terminals it was designed to run on have become mere footnotes in a writer's column.

As I discussed last month, the primary class for the interpreter is a public class with a factory method to create executable programs. I chose to implement this load method in a class named basic.Program. (For the rest of the article we'll assume the class names are all preceded by the "basic" package name without expressly calling it out.) Program exports a static method whose signature is:

To review last month's article briefly, there are two lexical-analyzer classes that are included with the standard Java distribution: StringTokenizer and StreamTokenizer. These analyzers convert their input into discrete tokens that a parser can use to understand a given input. The parser implements a grammar, which is defined as one or more goal states reached by seeing various sequences of tokens. When a parser's goal state is reached, it executes some action. When the parser detects that there are no possible goal states given the current sequence of tokens, it defines this as an error state. When a parser reaches an error state, it executes a recovery action, which gets the parser back to a point at which it can begin parsing again. Typically, this is implemented by consuming tokens until the parser is back to a valid starting point.

When writing Java applications, one of the more common things you will be required to produce is a parser. Parsers range from simple to complex and are used for everything from looking at command-line options to interpreting Java source code. In JavaWorld's December issue, I showed you Jack, an automatic parser generator that converts high-level grammar specifications into Java classes that implement the parser described by those specifications. This month I'll show you the resources that Java provides to write targeted lexical analyzers and parsers. These somewhat simpler parsers fill the gap between simple string comparison and the complex grammars that Jack compiles.

In this article we build a simple compiler that augments Java with tasks (independent blocks of code that execute in parallel), thus creating a new language called AJ that well supports the programming of systems with concurrent activities. This is not to imply that Java does not support multithreading, but to create a syntax that enables the clear expression of concurrency requirements. (AJ programs do, in fact, compile into Java programs that use java.lang.Thread objects to support tasks.) You will see how to use a completely visual, user-friendly parser generator, VisualLangLab, to quite easily build a compiler for AJ.