Re: CACM article (Feb 2009): "Compiler research: the next 50 years"

"Jason Evans" <joevans@gmail.com> wrote in message
news:09-02-045@comp.compilers...
>> > [For those of us whose ACM memberships expired a decade ago, what else
>> > does it say? -John]


> As far as the compiler research article is concerned, I have mixed
> feelings about its message. The basic tenet is that we should be
> working together on large systems, and stop wasting so much time
> implementing the same infrastructure over and over. The problem with
> that is similar to the problem with object-oriented programming and
> class reuse: the existing components are rarely a perfect fit for the
> project at hand. In each case, the cost/benefit of retrofitting has
> to be weighed against the cost/benefit of reimplementation.


Sure. But the article's point, I think, is that the decision to
rebuild compiler reseach infrastructures from scratch seems to occur
far too often.


When programs are small, perhaps rebuilding from scratch doesn't
matter much. Most compiler infrastructures fail the "small" test
pretty badly.


As far as I can tell, far too many groups (not just compiler types)
suffer from the Not Invented Here syndrome and *lots* of stuff gets
reinvented. (We just had a discussion about a fellow that wants to
produce yet another parser generator. To build a toy for education
reasons is fine, but he seemed pretty serious about trying to build a
real one. The point being .... what?) [I'll cheerfully acknowledge
that as an implementer of what I think of as a "compiler framework"
puts me directly in the NIH camp, too, but I'd like to think we added
enough interesting ideas so NIH wasn't the point],


So a useful thread we might start is,
a) what compiler infrastructures exist,
b) what is it about them, that doesn't satisfy most
needs of most researchers?


What do I think they need?
a) Strong parsing technology, so one doesn't waste vast amounts
of efforts building parsers. Our experience with GLR
is *really* good. (ANTLR, JavaCC seem ok
according other peoples's experience)
b) Means to build the standard compiler data structures
(trees, symbol tables, flow graphs, ...) that
are pre-exist, are modular and easy to use,
and are robust in the face of a wide
variaty of languages (e.g., can your flow graph model
the nondetermism present in C function call argument
evaluation?) [I'll scream if I hear about weaving
symbol table building into parsing one more time.]
c) Means to build standard flow analysis fact extraction
and composition (def-use, use-def, points-to, ...)
c) Robust front ends for many languages.
d) Means for computing relatively arbitrary facts
from basic facts. (Stanford has been pushing
Datalog as fact composition mechanism recently,
and I'm really envious of the idea).
e) Means to apply transformations in a straightforward
way. (I'm pleased that our tools let us do this
using source-to-source transformation patterns.
I'm not pleased in the sense that while these are
really useful, they have not turned out to be a panacea)


I don't know of many that meet this criteria. From what I understand
of it SUIF sort of does. IMHO, GCC is too tangled up being a compiler
to be helpful. What else exists?


--
Ira Baxter, CTO
www.semanticdesigns.com

Return to the comp.compilers page.
Search the comp.compilers archives again.