Re: Language features for compiler writing was: Java compiler courses

Chris F Clark wrote:
> 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.


Have a look into Haskell's Data.Graph.Inductive. The inventor wrote a
paper explaining it.[1] It is a graph library based on the idea that a
graph is either empty or can be decomposed into a node, it's edges, and
another graph. You would usually do flowgraph surgery by decomposing
the flowgraph to extract the node(s) of interest (every node must be
labelled by a distinct Int number, BTW), then re-assemble the graph with
new node(s) inserted. Because you are using structure decomposition,
the bits get GCed just like they would when you decomposed a parse tree.


    There are of course functions to check if the graph is disconnected,
though I doubt it would actually become so often enough to worry about.


-----
[1] Classic Haskell phenomenon: libraries that are documented only by
the research papers stemming from their development process.


--
Simon Richard Clarkstone:
s.r.cl?rkst?n?@durham.ac.uk/s?m?n.cl?rkst?n?@hotmail.com
Scheme guy says: (> Scheme Haskell)
Haskell guy says: (> Scheme) Haskell

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