[antlr-interest] Re: ITLS (was: Translators Should Use Tree Grammars)

[John D. Mitchell]

>>>>> "atripp54321" == atripp54321  <atripp at comcast.net> writes:
[...]

> John, Interesting read.  I don't know if my reply has anything to do with
> what you said, but here goes anyway :)

:-)

FWIW, I quite like your forthrightness in who you are and where you're
coming from.

> Now sometimes a whole different way of approaching the problem can work
> out in the end. For example, you might end up replacing a lot of C++/Java
> code with a a state machine or a set of "business rules" or whatever.

You do realize that any code is just a state machine, encoding the rules
for creating and transforming various internal and external relationships,
right?  The fact that that nature is obscured/lost is, IMNSHO, a
fundamental flaw of general purpose programmings languages.


> But requiring the application developer to change his mindset in such a
> major way is a major burden. It must be extremely clear at the end that
> there's a large benefit, as the developer will constantly be struggling
> to re-phrase the 'natural' algorithm that first pops into his head, into
> the new mechanism.

If all you know is how to use your claw hammer, you're not going to be a
very good carpenter (or handyman or electrician or plumber or CEO).

Nothing personal but I must say that I find an awful lot of the arguments
in the software world are nothing more than multi-party monologues where
each person is arguing "my claw hammer kung fu is always better than your
stupid nail gun kung fu".  Argue enough for your limitations and sure
enough, they're yours. :-)


> With lexers and parsers, the natural way to think about the problem is
> clearly specified with a BNF-like grammar. But with a complex AST-to-AST
> transformation, the natural thought process is to have a sequence of
> 'rules' like: "here are the steps to change the main() function".  This
> is much more intuitive then a set of actions embedded in the BNF-like
> grammar, as the thought process there is "Here are the things that I
> should do to translate a C FUNCTION_DEF to a Java one."

Again, you've described precisely what a tree grammar is for.  Your task is
translating from one language to another and a grammar is the fundamental
unit of language understanding and transformation.

[...]

> And so that's what I did. I started over, removed all the AST stuff, and
> spent the next two years working with token streams directly, building
> rules like that one.  It's horribly inefficient and error prone,
						      ^^^^^^^^^^^

"And that, my young apprentice, is why you fail [this lesson]."  :-)

As my "rule" pointed out, what you've done is spent a lot of time and
effort in (poorly) recreating language translation grammars.  Part of the
confusion is that you haven't realized/admitted that yet because you
haven't yet done the homework to learn the lingo (to be able to communicate
with the language translation community) and ways that people have been
developing and using in translation work for many years.

Take care,
	John


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/