Language features for compiler writing was: Java compiler courses

Again, let me preface my comments, by saying I think a functional
programming language like ML or Haskell is probably a best language
for a first compiler construction course (and perhaps a best first
language in general). Having said that, I want to backtrack and argue
some other points (and in the end ask a question).


Not to pick on this particular post, but it brings up issues I want to
address, so it's the candidate of choice.


torbenm@app-7.diku.dk (Torben Ęgidius Mogensen) writes:


> Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:
>
>> wooks wrote:
>>
>>> Why would anybody want to write a compiler in Java (unless it's the
>>> only language they know).
>>
>> What should the students learn: writing compilers in C, or writing
>> compilers in general?
>
> C is a horrible language for writing compilers due to bad
> infrastructure for tree and list structures (i.e., GC, polymorphism
> and pattern matching).


You can get polymorphism, by using C++ as your C. You should be able
to get pattern matching from your compiler-compiler (or other) add-on
tool. I don't know that you can in many cases, but you should be able
to get it, and if you can't that's a fault in the tool chain.


That leaves GC. You can get GC by going to Java (or C# or even
"managed C++"). More importantly, you can get poor-person's GC in a
variety of means (the Boehm collector) or a variety of coding
conventions. Now, all of those solutions are stop-gap and lack
something that real built-in GC gives one--essentially worry-free
programming (at least worry-free at one level).


Here is the point I want to debate/discuss. What C and its semantic
(if not syntactic) cousins Pascal and PL1/G have is the ability to
create a modify complex graph structures (with complex vertexes and
edges) in place (i.e. by side-effect). (This ability exists in all
languages where one can explicitly manipulate pointers and not just
lists.) Now this may be a dubious advantage, but it does make certain
things work well. There are times I would trade GC for this
advantage. Now, perhaps this just shows my age. Moreover, I don't
like trading pointers for higher-order-functions.


Moreover, since long practice has shown that most people (me included)
are not competent at mantaining the discipline to write bug-free
programs when using that advantage, perhaps it is a good thing to have
banned. However, it is the model that the C-level programming
languages support. Perhaps, there is a monad in Haskell that allows
one to write the same code in a more type-secure way, but unless there
is, there are still some advantages to languages with C's disregard
for safety that let you write what you need.


On the other hand, people have known how to simulate the feature since
at least the time of FORTRAN. One simply uses integers as indexes
into parallel arrays. One array for each different field (member) of
the vertex (or edge) type. In fact, some code I'm hacking on right at
the moment uses exactly that technique. Plus, one can make the arrays
be arrays of structures and thus keep them automatically in sync.
However, there is something missing in this method. Part of that is
that the direct reference syntax isn't quite "pointer-like" (and that
could be fixed by syntactic sugar). However, I think the real issue is
that the elements are not independent objects in themselves. That is,
the GC will not come along and say index 10 is no longer referenced
and we can eliminate (collect) array[10].


So, this is the question, is there an FP technique that allows
inidividual elements of an array (list, bag, someother roughly
equivalent structure) to be addressed and arbitrary (i.e. cyclic)
graphs to be constructed (and rearranged) on-the-fly, but where
unreferenced elements get collected? If so, where can I learn about
it?


-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

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