Program for displaying graph state in lambda interpreter?
Hi, I have written an interpreter that operates on the lambda calculus augmented with letrec, constructors, case, primitive objects, and builtin operations. I'd like to display the internal state of the intepreter at various points so that I can, um, debug the "programs" that I've written. Currently I've got about 3500 nodes, and I'm dumping a graph that I format using the 'dot' program in graphviz. I might have "let x = 1+2 in x*x" represented as. x/1: <2>+<3> 2: 1.0 3: 2.0 4: <1>*<1> where <1>, <2>, <3>, represent various memory locations. I can display this in graphviz, where each node is a rectangle containing text like "<1>*<1>" and there are arrows from the rectangle to <1>. This works as long as the number of nodes isn't very large. However, it would be nice to know of any programs that are better suited for this. For example, if I could write <>*<> and draw arrows from the placeholders "<>" to the memory location being referenced, that would be easier to read. This is done here http://en.wikibooks.org/wiki/Haskell/Graph_reduction to illustrate that 'square (1+2)' doesn't evaluate 1+2 twice. Any ideas? thanks, -BenRI P.S. If this is too off-topic, please let me know.
Hi Benjamin, On Fri, Jun 1, 2012 at 9:54 PM, Benjamin Redelings wrote:
I have written an interpreter that operates on the lambda calculus augmented with letrec, constructors, case, primitive objects, and builtin operations. I'd like to display the internal state of the intepreter at various points so that I can, um, debug the "programs" that I've written.
Currently I've got about 3500 nodes, and I'm dumping a graph that I format using the 'dot' program in graphviz.
[...] However, it would be nice to know of any programs that are better suited
for this. For example, if I could write <>*<> and draw arrows from the placeholders "<>" to the memory location being referenced, that would be easier to read. This is done here http://en.wikibooks.org/wiki/** Haskell/Graph_reductionhttp://en.wikibooks.org/wiki/Haskell/Graph_reductionto illustrate that 'square (1+2)' doesn't evaluate 1+2 twice. Any ideas?
This may not answer your question, but it might be related and/or helpful: http://rochel.info/#graph-rewriting Regards, Sean
On 06/01/2012 05:07 PM, Sean Leather wrote:
Hi Benjamin,
On Fri, Jun 1, 2012 at 9:54 PM, Benjamin Redelings wrote:
I have written an interpreter that operates on the lambda calculus augmented with letrec, constructors, case, primitive objects, and builtin operations. I'd like to display the internal state of the intepreter at various points so that I can, um, debug the "programs" that I've written.
Currently I've got about 3500 nodes, and I'm dumping a graph that I format using the 'dot' program in graphviz.
[...]
However, it would be nice to know of any programs that are better suited for this. For example, if I could write <>*<> and draw arrows from the placeholders "<>" to the memory location being referenced, that would be easier to read. This is done here http://en.wikibooks.org/wiki/Haskell/Graph_reduction to illustrate that 'square (1+2)' doesn't evaluate 1+2 twice. Any ideas?
This may not answer your question, but it might be related and/or helpful:
http://rochel.info/#graph-rewriting
Regards, Sean Thanks Sean,
The note on Very Lazy evaluation was quite interesting. I can't directly use the graph rewriting libraries, though, since the interpreter is written in C++. -BenRI
Benjamin Redelings
However, it would be nice to know of any programs that are better suited for this. For example, if I could write <>*<> and draw arrows from the placeholders "<>" to the memory location being referenced, that would be easier to read. This is done here http://en.wikibooks.org/wiki/Haskell/Graph_reduction to illustrate that 'square (1+2)' doesn't evaluate 1+2 twice. Any ideas?
Have a look at Brent Yorgey's 'diagrams' package:
http://projects.haskell.org/diagrams/
It does not do the automatic balancing that Graphviz does, but is a nice
generic drawing library for diagrams. In particular I assume that the
initial graph of your programs is actually a tree, for which diagrams
should be very well suitable.
Greets,
Ertugrul
--
Key-ID: E5DD8D11 "Ertugrul Soeylemez
participants (4)
-
Benjamin Redelings -
Benjamin Redelings I
-
Ertugrul Söylemez -
Sean Leather