Monthly Archives: June 2004

ACDK is an interesting bit of work that does not seem to have attracted a lot of notice.

Since I do a fair amount of cross-language coding, am looking to build in support for scripting (for a Windows-based product), and am aiming to migrate the product from Windows-only to something more portable – for this entire collection of reasons ACDK is an interesting bit of work.

A good argument for open-sourcing Java at: The Cliffs of Inanity.

There are other arguments.

The article What The Perl Community Needs Is a Good Enema gives me hope things might break loose in a useful way.

I really like Perl for some sorts of problems, and the CPAN library is wonderful. I really like Java for other sorts of problems, and the amount of available stuff in the Java world is amazing. Too bad these two worlds are so isolated, as it would be even more effective if you could call Perl directly from Java (and the reverse).

In fact with enough contortions it is possible to call between Perl and Java – but I’d not use “easy”, “graceful”, or “elegant” to describe the result.

The Microsoft folks really do have the right notion with the “Common Language Runtime” (CLR).

The Perl folks are off inventing their own virtual machine (“Parrot”). Why invent another virtual machine? Isn’t this just hubris? Why not use a JVM? At least the notion of calling between Perl and Java should end up easier.

OK, I know that Perl is open source and Java is not. Hopefully Sun will get around this hangup someday.

I know that Java bytecodes might not be ideal for Perl, though better JIT in JVM’s from Sun and IBM may negate much of that theoretic difference.

Virtual machines (today) and microcoded machines (in the past mainly) have a great advantage in that you can tweak or add instructions to suit your workload. At the time I was at Burroughs they realized that while the Large Systems microcode was ideal for ALGOL, must of their customers were running mainly COBOL code. After some benchmarks they had enough information to go into and slightly re-work the microcode to greatly enhance COBOL performance.

If both parties can get past the ego issues and work together, I believe we could see slightly enhanced JVMs that do a good job with Perl code.

Seems Keith found my prior reference too obscure. I was assuming that a someone fluent would Lisp could draw the analogy without help, and folks unfamiliar with Lisp probably could not follow the analogy without way more writing than I have time to do.

On reflection, that left out the folks not yet fluent with Lisp, so Keith’s puzzlement is justified.

The Ada project at UCI took a brilliantly simple approach. A recursive descent parser translated the Ada source text into a parse tree. The parse tree was (naturally) a Lisp s-expression, and could be saved and loaded using the usual Lisp save/load functions. The interpreter, pretty-printer, and compiler methods were attached to the Ada parse tree node identifiers as properties. This made for very small code fragments that were very quick to write.

For example the calling the Ada interpreter was simply:

(ada-interpreter parse-tree)

and the code executed was like:

(ada-eval (getprop 'ada-interpreter (car parse-tree)) (cdr parse-tree))

The code fragment to interpret an IF statement might look like:

(cond
((ada-eval (car statement)) (ada-eval (cadr statement)))
(T (ada-eval (caddr statement))) )

(I threw out my UCI Lisp manual years ago, so the above is only vaguely correct).

The pretty-printer and compiler were similarly simple. The full-screen Ada editor (hot stuff at the time) ran the Ada pretty-printer to format the parse tree as the text to be edited, and on save ran the Ada parser to generate a parse tree from the text (and parse errors put you back in the editor).

The fact that the interpreter/editor/debugger were all components in the Lisp environment and readily extensible was a huge advantage.

In the Java world we get many of the same advantages. The Java compiler is simply Java code, and can be called by Java programs (though the overhead is higher). If you are using any of the Java IDEs with well-documented interfaces, it is possible to extend your programming environment.

In the XML world you get arbitrary self-describing data structures – a lot like data stored as Lisp s-expressions, only needing a bit more storage for the same data. XML is cool in almost exactly the same way that storing data is Lisp s-expressions was extremely useful. Walk an XML tree with a hash table on the side, and you get the same result as Lisp s-expressions with properties attached to identifiers in each node.

In a sense the Java + XML world is re-discovering some of the useful notions readily available to Lisp programmers twenty-odd years ago.