[antlr-interest] philosophy about translation
Andy Tripp
antlr at jazillian.com
Fri Oct 27 07:31:47 PDT 2006
Anthony W. Youngman wrote:
> In message <452D3180.2070907 at jazillian.com>, Andy Tripp
> <antlr at jazillian.com> writes
>
>>> "Thinking in trees" does not come automatically. It is like
>>> learning LISP or Forth or one of the functional languages (and, for
>>> that matter, object-oriented programming: there is a lot of badly
>>> designed and implemented C++ code out there). For a time, working
>>> with trees is like slogging through molasses, and then you get the
>>> "Aha!" experience and things become easy. It usually is not about
>>> designing the perfect tree structure; instead, it is about
>>> simplifying the recognition problem and expressing target language
>>> constructs in tree form.
>>
>>
>> For the record, I had no trouble "getting" LISP when I learned it 25
>> years ago. When I started with C++, I don't think I
>> really "got" OOD, and only started writing real OO code when learning
>> Java forced me to. I think the fact that LISP never
>> became "mainstream" means that it failed to be easy enough to grasp.
>> Regardless of how inherently beautiful it is,
>> if a lot of programmers don't easily "get it", then it's not that great.
>
>
> The trouble is, the "average" programmer is just that, average.
>
> A great programmer can do the work of ten ordinary programmers. The
> trouble is, he probably does it with tools that are beyond the ability
> of the ordinary programmer to "get".
Just to be clear, I'm not saying I'm an "average" programmer or looking
for tools for the "average" programmer.
I might be in the top 2% of all programmers, but I'm not in the top 0.1%
of language-tools-gurus as Terence is.
So I want tools that helps us good-programmers-but-not-compiler-gurus
build stuff.
I'm not a Terence looking to automate my parser-creation task;
I'm just an Andy looking to build a language translator while barely
knowing the difference between LL(*) and LL(k).
Just as a compiler lets the programmer focus 100% on the problem at hand
(application logic) and 0% on
the underlying level (creation of object or byte code), ANTLR lets me
focus on the problem at hand
(lexing and parsing) and not the underlying level (creation of
lexing/parsing code). Unfortunately, I
don't think there's one really good tool for hiding the whole "language
translation" level. ANTLR treewalking
combined with StringTemplate attempts to do that, but falls short in two
ways, I think. First, ANTRL treewalking
requires perfect knowledge of the input language structure. And second,
I don't think treewalking is the better
way to slice the problem, as the problem scales up. In other words, when
you have a ton on translation logic,
"Here are each of the translation rules I'd like to apply" is a better
way to approach it than
"Here is what to do at each node of the input structure tree".
More information about the antlr-interest
mailing list