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

Simon Richard Clarkstone <s.r.clarkstone@durham.ac.uk>
29 Apr 2007 19:00:44 -0400

          From comp.compilers

Related articles
[4 earlier articles]
Re: Language features for compiler writing was: Java compiler courses torbenm@app-2.diku.dk (2007-04-27)
Re: Language features for compiler writing was: Java compiler courses DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-27)
Re: Language features for compiler writing was: Java compiler courses la@iki.fi (Lauri Alanko) (2007-04-28)
Re: Language features for compiler writing was: Java compiler courses jon@ffconsultancy.com (Jon Harrop) (2007-04-28)
Re: Language features for compiler writing was: Java compiler courses DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-04-28)
Re: Language features for compiler writing was: Java compiler courses danwang74@gmail.com (Daniel C. Wang) (2007-04-28)
Re: Language features for compiler writing was: Java compiler courses s.r.clarkstone@durham.ac.uk (Simon Richard Clarkstone) (2007-04-29)
Re: Language features for compiler writing was: Java compiler courses torbenm@app-5.diku.dk (2007-05-04)
Re: Language features for compiler writing was: Java compiler courses dot@dotat.at (Tony Finch) (2007-05-04)
| List of all articles for this month |

From: Simon Richard Clarkstone <s.r.clarkstone@durham.ac.uk>
Newsgroups: comp.compilers,comp.lang.functional
Date: 29 Apr 2007 19:00:44 -0400
Organization: University of Durham, Durham, UK
References: 07-04-074 07-04-084 07-04-109 07-04-125
Keywords: design
Posted-Date: 29 Apr 2007 19:00:44 EDT

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


Post a followup to this message

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