Here's some interesting stuff about the design and development of Relax NG:
James Clark wrote about maximizing composability:
First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.
Clark describes the derivative algorithm's lazy approach to automaton construction:
I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the "derivative"-based approach in JTREX as lazily constructing a kind of automaton where states are represented by a canonical representative of the patterns that match the remaining input.)
The Relax NG derivative algorithm is implemented in a few hundred elegent declarative functional lines of Haskel, and also in tens of thousands of lines and hundreds of classes of highly abstract complex Java code.
Clark's Java implementation of Relax NG is called "jing", which is a Thai word meaning truthful, real, serious, no-nonsense, and ending with "ng".
Comparing the Java and Haskell implementations of Relax NG illustrates what a wicked cool and powerful language Haskell really is. The Java code must explicitly model and simulate many Haskel features like first order functions, memoization, pattern matching, partial evaluation, lazy evaluation, declarative programming, and functional programming. That requires many abstract interfaces,, concrete classes and brittle lines of code.
While the Java code is quite brittle and verbose, the Haskell code is extremely flexible and concise. Haskell is an excellent design language, a vehicle for exploring complex problem spaces, designing and testing ingenious solutions, performing practical experiments, weighing trade-offs, and writing succinct, elegant, mathematically rigorous specifications that actually work. Haskell code is useful as a blueprint for implementations in less luxurious languages like Java.
In The State of XML, Edd Dumbill explains the secret behind the success of Relax NG:
Incidentally the RELAX NG success can equally well be framed as a case of design-by-inspired-individuals vs. design-by-committee as much as it can be seen as a OASIS vs. W3C thing.
James Clark is a fucking genius! He’s the guy who wrote the Expat XML parser, works on Relax NG, and does tons of other important stuff. Relax NG is an ingeniously designed, elegant XML schema language based on regular expressions, which also has a compact, convenient non-xml syntax.
I totally respect the way he throws down the gauntlet on operator precedence (take that you Perl and C++ weenies!):
There is no notion of operator precedence. It is an error for patterns to combine the |, &, , and - operators without using parentheses to make the grouping explicit. For example, foo | bar, baz is not allowed; instead, either (foo | bar), baz or foo | (bar, baz) must be used. A similar restriction applies to name classes and the use of the | and - operators. These restrictions are not expressed in the above EBNF but they are made explicit in the BNF in Section 1.
You can translate back and forth between Relax NG's XML and compact syntaxes with full fidelity, without losing any important information. Relax NG supports annotating the grammar with standard and custom namespaces, so you can add standard extensions and extra user defined meta-data to the grammar. That's useful for many applications like user interface generators, programming tools, editors, compilers, data binding, serialization, documentation, etc.
The schema starts out by defining a few namespaces:
default namespace = "http://www.laszlosystems.com/2003/05/lzx" namespace rng = "http://relaxng.org/ns/structure/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" namespace lza = "http://www.laszlosystems.com/annotations/1.0"
The a: namespace defines some standard annotations like a:defaultValue, and the lza: namespace defines some custom annotations private to the Laszlo compiler like lza:visibility and lza:modifiers. Thanks to the ability to annotate the grammar, much of the syntax and semantics of the Laszlo programming language are defined directly in the Relax NG schema in the compact syntax, so any other tool can read the exact same definition the compiler is using!
To show how truly simple and elegant it is, here is the snake eating its tail: The Relax NG XML syntax, written in the Relax NG compact syntax:
Laszlo Mail is a rich web email application that runs in any web browser on any kind of computer with the Flash player. It's written in OpenLaszlo. Earthlink is deploying Laszlo Mail to their customers, and Laszlo Systems has released this demo version for free on their own servers. Give Laszlo Mail a test drive -- be sure to check out the contact details, search interface, the wysiwyg email editor, spelling checker, and how the user interface adapts as you resize the window. You'll see why I'm so excited about OpenLaszlo!
I worked on Laszlo Mail for Laszlo Systems as a contractor, developing the drag-and-drop email folder tree, and also the attachments upload component, so I'm biased of course. I'm applying what I learned by working on Laszlo Mail to developing my own Laszlo applications. I like OpenLaszlo because it's open soure, really fun to program, supports full-blown user-friendly rich graphical interfaces, and scales up well to handle heavy duty tasks like reading email.
Here's an interesting audio interview with Dave Temkin, CTO of Laszlo Systems. They cover some important topics and Dave makes some great points that explain why OpenLaszlo is so exciting.
They discuss why Laszlo was open sourced, why open source software is so important, what the ideas behind Laszlo's design are, why Laszlo uses Flash, how it actually operates at a higher level independent of Flash, what the technologies that led to the Laszlo application language were, how Laszlo integrates open standard technologies, how it relates to AJAX and DHTML, which companies and applications use Laszlo, which software development tools support Laszlo, how the user base is growing now that it's open source, what kinds of reusable components and widgets are Laszlo Systems developing, what opportunities exist for web developers and user interface designers, and where Laszlo is headed in the future.
There's a lot I like about OpenLaszlo. It has all of the advantages and none of the problems of the NeWS Window System, which was a technological success that failed because it was proprietary. I was daydreaming about having a system like Laszlo in 1998, and while I was intrigued by Flash, I avoided it for all the obvious reasons. But nothing can hold a candle to Flash's market penetration, graphical quality, and consistency across platforms.
The important thing about OpenLaszlo, which will ensure its long term success, is that it doesn't lock you into the Flash player, even though it takes advantage of Flash as a standard ubiquitous runtime. Laszlo is abstract from the Flash player, and it will output to other platforms over time as they mature, such as DHTML, Java and .NET.
The interview is an audio "podcast," and there's no text transcript available, but here's the blurb about it:
David plans to leverage rich client environments other than Flash Player, such as DHTML, Java and .Net and shares his about thoughts about Eclipse, the recent Adobe/Macromedia merger, refactoring the desktop user interface and calendar interoperability. He also explains why Flash is not an ideal platform for mobile devies and desktop applications and compares Laszlo Blog Boxes to widgets in Apple's Dashboard and Yahoo's Konfabulator.
Today, Grig and I were discussing how to evaluate arbitrary mathematical expressions in Laszlo applications, in the absence of "eval".
I think it would be easy to implement a simple rpn stack machine like PostScript, that used string.split(" ") to break a string apart into tokens, which Flash can do fast.
So I hacked up this Laszlo interpreter class that behaves almost but not quite completely unlike a PostScript interpreter.
This is the documentation for the OLE Automation Interface to Transmogrifier (version 2.1.2 and greater).
This is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), about his experiences at the MIT AI Lab, and the story of the Lisp Machine Wars.
Machine Room Folk Dance, Thursday at 8pm.
Come Celebrate the Joy of Programming,
with the World's Most Unbureaucratic Computers.
(There were only five of us dancing, but we had a good time.)
My first experience with computers was with manuals for various languages that I borrowed from counselors at camp. I would write programs on paper just because of the fascination of the concept of programming. I had to strain to think of what the programs should do, because I had nothing to supply me with a goal except that I wanted to program. I wrote programs to add up the cubes of a table of numbers in several assembler languages at various times.
The first actual computers I met were IBM 360's, at the IBM New York Scientific Center, when I was a student in high school. There I quickly developed interest in language design, operating systems and text editors. Hired for the summer to write a boring numerical analysis program in Fortran, I surprised my boss by finishing it after a couple of weeks and spent the rest of the summer writing a text editor in APL.
I also quickly manifested a lack of proper reverence for authority. The whole center had been denied access to the IBM computer in the building, and we had to use slow telephone connections to the Cambridge Scientific Center. One day an IBM executive came to tell us about the work various IBM scientific centers were doing, and finished with, "Of course you all know the important work being done here." I asked him, "If our work is so important, why can't we use the computer in this building any more?" After the meeting, my friends told me they had wanted to say such a thing but were afraid of reprisals! Why? Certainly nothing happened to me as a result. They seem to have learned the habit of cowering before authority even when not actually threatened. How very nice for authority. I decided not to learn this particular lesson.