[antlr-interest] soliciting language recipes book outline feedback
Terence Parr
parrt at cs.usfca.edu
Mon Jan 7 10:39:48 PST 2008
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
More information about the antlr-interest
mailing list