I had started working on a treelang-like front end that conforms to the
GCC conding style, targets GENERIC and is completely standalone. It
produces a few non-GENERIC nodes in the parser to show how lowering the
parse tree to GENERIC would work. I wanted it to follows
sourcebuild.texi and frontend.texi to the letter.
That all sounds like a good idea.
I also wanted the parser to build the parse tree using 'tree' and to
build funtions as trees. I know you probably do not like parsing
directly into 'tree', because treelang now shows how you can _not_ build
trees and still interface with GCC, like most existing front ends (G77,
G95, Ada, COBOL and a few others) actually do. But using trees from the
start makes the front end much smaller. I used trees because I just
wanted to see how it would look, but I can see why you choose
differently. It is a matter of what you want to show with treelang.
My preferance is for a separate parse tree. Even though this may make
the source code longer, I still think this is better, because I think
the separation makes it easier to understand the GCC front-end interface.
Also this approach scales better to real systems and is the sort of
approach that we should encourage for new front-ends.
So, what do we _want_ to show with treelang? What is the function of
treelang within GCC and what implications does that have for its design?
The purpose of treelang within GCC, IMHO, is to provide a simple but
complete and working didactic example of a front-end, in order to make it
easier for people to understand the front-end interface, and to provide
something that people writing a new front-end can use as a model on
which to base their front-ends.