Currently syntax errors cause invalid trees and possibly even runtime exceptions when building ASTs. What we really need I believe is to have rules that encounter syntax errors return an ERROR node of some sort that records where the error occurred and, with luck, the tokens consumed during recovery. I started an improvement request:

http://www.antlr.org:8888/browse/ANTLR-193

The basic idea is that ERROR nodes get used in place of ASTs that would normally be produced by rule indications....

just had some cool ideas about a semantic rule specification language...i should write that up too... (also think about multi-threaded rewriting; no side-effects required

Some language translation problems can be described with a few rewrite rules that are predicated upon their context and potentially an arbitrary Boolean expression. For example, consider a few identity transformations such as

expr: // in context of expr, match left side,...

Currently ANTLR does not create templates for you automatically when you use output=template option. This is because, when I first implemented it, I had no idea what the right answer was here. I did not know how to deal with whitespace and so on. I think I have the answer now. First, let me remind you that output=AST builds a completely flat tree given no instructions to the contrary. Similarly, the template output should reproduce the input given no instructions.

...

Ok, Kay Roepke is in town and we've been discussing the faster expression parsing, among other things. Look for another entry on default StringTemplate generation or a parsing and tree parsing.

ANTLR v3.2 will allow special rules for specifying expressions that are particularly efficient both in speed and space. Special rules will define either unary suffix operators, binary operators, or trinary operators by virtue of how they recurse....

I should be working on something else but got to thinking about how annoying it is specifying expressions in recursive descent parsers. You have to have a new rule for each precedence level. This is also very slow. Just to match 34 it has to descend about 15 method calls. I built a prototype single-rule (plus primary and suffix) operator matching thingie which I enclose below. I should be able to generate it from some metameta syntax in antlr. For example,...

I replaced my blocking queue sitting between pipeline actors (threaded consumer/producers) and speed of my word freq program dropped from 5.2s to 3.5s on 5M file simply by replacing the blocking queue with my new ping-pong buffered version. That is close to the 3.0s achieved by the nonthreaded version.

// threaded, pipeline version; 3.5s (from 5.2s) on 5M file
f => Words() => { string w | ... }

// nonthreaded, nested map operation on big list; 3.0s
f....

So I am narrowing down my understanding of how to use mixins. The Comparable example is awesome, but does not need fields. In my effort to reduce the size of the average mantra object, I needed to remove the in and out fields from every object. The should be moved to an element that all of the actors can include or inherit from. I did not want to force all actors to inherit from the same base class, so I decided that a mixin was perfect but mixins don't currently allow fields....

Finally got something ready for people to look at. Main components are in.

http://www.linguamantra.org/

Awesome. Mantra does a dynamic mixin. Just map a string to a closure with "self" as first arg:

int.mixin("toHex",
   {int self | return java {new mstring(Integer.toHexString(((mint)self).v))};}
);
println(32.toHex()); // emits 20, the hex verison of 32. :)

also note you could alter the MetaClass per object (set .class field) to alter behavior per instance! You can ask about meta object now:

println(32.class); // emits <int>

To avoid strange bugs,</int>...

Check this out:

ErrorMgr errors = ErrorMgr(); // answers error()
Vehicle.delegate(errors);
Car c = Car(); // car does not answer error()
c.error("we crashed");

here I am calling the delegate method on the Vehicle class, of which Car is a subclass. I make an instance of a car and then send it the error message, which is forwarded to the error manager....

See http://www.linguamantra.org for more information.

Type annotations

Mantra is not a statically typed language like Java, though you'll see types specified in the code. These types are annotations kind of like "executable documentation". For example how many times have you done this in other dynamically typed languages like Ruby and Python:

f(a): ......

Mantra is coming along nicely. Added type annotations, but am not doing anything with them yet.  Without much optimization (and huge amounts of memory allocation), Mantra loop and list append are looking good:

a = [];
1..5000000:{int i | a += i;};

The equivalent python:

a = [];
for i in range(5000000):
        a.append(i);

My unscientific wallclock measurements on my dual cpu mac (powerpc) with Java 1.5 shows Java doing about 3.0s vs 3.9s in python....

I just finished adding heterogeneous AST node types to the tree construction. I did not get a response on the mailing list about what people needed, so I build what I thought I would need. The mechanism is extremely simple. If you want a specific node type for a token type, simply switch on the token type inside the TreeAdapter. When you need to use a specific node type for the same token type depending on grammatical context, then ANTLR needs to let you specify that....

Working on design for tree grammar rewriting. I want to be able to tweak a tree w/o having to rebuild whole tree. Imagine

a : ^(A B c D) ;
c : C -> E F ;

which means replace the C with E F using a rewrite rule. Suppose we only want to alter the 2nd child of A and not the whole tree. I want to avoid a bunch of extra generated code in favor of making the tree node stream track current child number and start/stop index for rule invocation....

Spent a few hours talking to Kay Roepke as he is in town for 10 days. He and I started looking at the tree diff mechanism he found on the net and we discussed how it would be included into antlr. Also we discussed grammar composition. Seems to me there are four problems in the area of reusing grammars:

1. Island grammars (probably best handled by a scannerless parser); ignored for the purposes of this discussion
2. Combining and sharing grammars (multiple variations on C, SQL, etc......