[antlr-interest] soliciting language recipes book outline feedback

[Terence Parr]

On Jan 1, 2008, at 2:39 AM, Harald M. Müller wrote:

> Hi -
>
> At minimum, I would require that there are two solutions for many (?  
> - a few
> important) of the examples. In the real world, there is not "the  
> solution."
> (and of course, not both/more solutions need to be done down to  
> code ... but
> there should - like in any good patterns book - be enough meat so  
> that the
> problems are made clear when solving one over the other solution;  
> I'm very
> convinced that there is never ever a "perfect solution" in your  
> business).

Yes, I think that is a good idea to at least discuss the different  
approaches with their various benefits and disadvantages.

> Just to lay out that "design space" a little: Whether you
>
> * do your work in the parser;
> * create an AST and do your work there;
> * create an AST, rewrite in to another AT, do your work there;
> * create a complete different structure (e.g. a flow graph [think  
> "byte
> code"]) to do your work;
> * create an AST, the create the different structure and do your work  
> there;

Yup, though we had to be careful not to write a textbook; I'm doing  
that one next :)

> Before I ever start laying out a grammar, I write down this design  
> space for
> a tool - which sometimes results in creating an AST at a time where  
> this
> seems "way to complicated" - but I know it will help with that "tiny
> language extension" they are already talking about ... or the  
> opposite:

yup

> Seeing that a generalization (even a small one) requires much work,  
> I reduce
> the machine to a "small one" (and will bill the customer for the  
> large one
> when he really claims to need it ...).

ha! :)

> Second, there should probably be advice on when/where to stop using  
> ANTLR.

Yeah, I wanted to do a number of things was just code and with awk/sed  
and with Python or Ruby.

> The two "boundaries" that right now come to mind are
> * XML - you can do something with ANTLR here (see a few great Wiki  
> entries),
> but of course there are lots of XML-specific technologies;
> * rewriting - when a rewriting solution is going to become a  
> "calculus,"
> other tools (one was mentioned here a few days ago ...) might be a  
> better
> choice - but why?
>
> .... just my two cents (also why I find today's wiki entries  
> somewhat ad-hoc
> ...).

  thanks for the feedback Harald!
Ter