ActionScript 3.0 Interpreter Design Pattern
Back in the day I used to do a lot of FORTH programming. For about 10 years I’d attend a weekly meeting of FORTH programming engineers at General Dynamics in San Diego and marvel at what they could do with this postfix language. (Postfix is often called reverse Polish notation after the Polish mathematician Jan Łukasiewicz who developed the mathematical notation placing the operator after the operands.) The following shows an example of this notation:
30 2 * 4 +
Result: 64
Later, when Adobe came out with PostScript and Apple came out with their first laser printer, I was able to program in PostScript using a text editor and shooting it directly to the printer. Out would come these fabulous fonts, drawings and whatever else I had programmed in. Because PostScript used a similar postfix notation as FORTH, I was allowed to do a FORTH newsletter in PostScript. Only a few were produced since it was no easy task to develop a newsletter in code using Notepad! (Click here to see the final PostScript calculator that this application generates. It works with PostScript data entry — use add, sub, mul, and div for +, -, *, and / respectively.)
Interpret This!
The Interpreter design pattern as described by Gamma, et al can be used to express instances of a recurring problem as sentences. Interpreting the sentences then solves the problem. Right off the bat I was thinking, ¿como está usted? translates to how’s it going? but that’s not exactly what GoF had in mind. Any spoken language is a bit too big for this kind of interpreter. Instead, the pattern describes how to define a grammar for simple languages. Gamma and his associates use the example of regular expressions, so loved by Perl programmers.
So when I went looking at some Interpreter examples, besides regular expressions, I found converters from Roman numerals to regular numbers, a Boolean language, a musical note interpreter from do, rey, me, fa, so, la, ti to Hertz (Hz) values, calculations using postfix notations and some other fairly modest examples. Because of my experiences with postfix languages, I decided to do one that set up as a PostScript data entry that would resolve to an outcome (solution) to the results of a postfix statement. I decided on PostScript whose math operators are word-like and not symbols. (e.g., Instead of using / for division, it uses div.) This would be a little more than the usual minimalist example since the user can use it to practice and learn PostScript math entries.
Interpreter Design Pattern Formal Features
Figure 1 provides an overview of the Interpreter pattern. Note that the Client is part of the pattern (instead of implied or not at all). Also note that the Client holds references to both the Context class and AbstractExpression interface.
Figure 1: Interpreter Class Diagram
Of all of the design patterns I’ve seen, this one has the most loose ends. Any statement put into a string and then interpreted generally requires some kind of parsing. GoF note the need for parsing and point out it can be from a table driven source, a recursive descent (or some other hand-crafted parser) or in the Client. The Context class is used as a global entry point for the Interpreter. It’s probably heresy to do so, but I decided to put the parser in the Context. The Client sends the request to the Context and indirectly to the AbstractExpression. The Context class still acts as a global entry point, but it also parses the data (statement in PostScript notation), and the Terminal Expression classes still do the actual interpretation. I don’t see it as adding tighter coupling. (If the parser were placed in the Client, I suppose it would be a purer version of the design pattern. If you think so, I’d like to see your implementation, and I’d be glad to put it on this blog.) Also, like most of the examples that I saw, this one does not include a NonterminalExpression. That is because I did not need alternation, repetition or sequence expressions.
The good news is that this implementation of the design pattern is wonderfully flexible and easy to update. If I wanted to change the language example from PostScript to something like Scheme, the pattern would be able to handle it with ease. Eventually, I’d like to re-do it with the parser in the Client and add several PostScript drawing commands by adding more terminal expression classes. I’d also like to add a NonterminalExpression for handling certain repetitions and sequences.
Continue reading ‘ActionScript 3.0 Interpreter Design Pattern: A PostScript Tutor’
Bill Sanders
Recent Comments