[antlr-interest] Why no links to ANTLR 3.0 on www.antlr.org??

[Terence Parr]

On Jun 4, 2005, at 1:47 AM, Gerald B. Rosenberg wrote:
> I will try to take a constructive stab at this.  Given that the  
> problem space and tool are respectively very complex and capable of  
> very complex operation, the documentation is just too eager.

I assume you meant "meager" ;)

>   It presents something basic and then jets off mixing a bunch of  
> fairly complex potential uses together which makes following and  
> understanding any one very difficult.

Damn!

> For example, under http://www.antlr.org/doc/trees.html#_bb4, there  
> is brief introduction to marking lexer tokens as roots.  Ok.  Then  
> some stuff about building trees.  Nothing there about parser tokens  
> as roots.

Apparently the doc is worst than that!  What do you mean by parser  
tokens?  Do you mean imaginary tokens inserted by the parser for  
which no actual input lexeme exists?

>   I think that is what I need for my problem -- I need to  
> understand better how ANTLR wants to mark and construct parser  
> trees.  So, is marking a new parser token as a root even possible?   
> Well, keep looking down.  Token translation.  Ok.  Token  
> factories.  Ok, I guess.  Heterogeneous ASTs.  Ok, real advanced.   
> Fairly certain that is not applicable to my initial needs.

Interesting...define parser token for me and I'll try to help.

> Finally! An first example ("An Expression Tree Example").  Maybe  
> that will walk me through enough to understand how ANTLR wants  me  
> to solve my problem.
>
> Problem statement: a simple value accumulator implemented using a  
> simple tree.  Ok, not really close to my case I think, but sounds  
> like it has a similar level of complexity so I should be able to  
> learn bunches from it.
>
> OH, NO: Third paragraph, the "formal statement of the explanation  
> of the solution to follow":
>
> "The AST operator nodes must combine the results of computing the  
> value of their two subtrees.  They must perform a depth-first walk  
> of the tree below them.  For fun and to make the operations more  
> obvious, the operator nodes define left() and right() instead,  
> making them appear even more different than the normal child- 
> sibling tree representation.  Consequently, these expression trees  
> can be treated as both homogeneous child-sibling trees and  
> heterogeneous expression trees."
>
>
> ??? Fun and obvious???  Make them appear more different???  A  
> straight first example?  No.  More accurately an advanced  
> transvestite example.

Did any of the examples or tutorials help?  The doc is not  
particularly friendly.

> There are so many issues working in this example, I challenge  
> anyone not already an expert to readily tell what design features  
> pertain to what -- what is there for fun and what select parts are  
> essential for the particular purposes relevant to a relative new- 
> comer's basic issues of understanding.  The question is, would  
> someone not capable of authoring this example in the first place,  
> now understand matters well enough to go back and author the  
> simple, straight-forward version?

Sounds like we have a navigation issue not doc issue (though I plan  
on fixing the doc).  Did you see my course notes and all that jazz?

> Now, don't get me wrong: I am not advocating plodding  
> documentation.  Enthusiasm is a great tool for maintaining interest  
> in the narrative, particularly on paper.  There just needs to be  
> something of a middle ground (at least for us middle of the road  
> programmers).

Can you lay out precisely what you've read / looked at what you  
haven't?  That will tell me a lot!  As I say, it may be simply that  
the information is not available in the proper order or even defined  
in what order you should look.

Ter