[<<][staapl][>>][..]
Mon Jun 9 15:46:14 CEST 2008

representing DAGs

"It's better to separate the 2 concepts of many->one functions and
grouping, than to work with many->many functions and permute/connect
their outputs.

What this does for representing graphs is the ability to use simple
nested (scheme) expressions.

In this view, mapping a concatenative language to an expression based
syntax is completely trivial. Representing one is completely trivial
also. So what problem am I solving?

( Some idea is itching in the back of my head telling me that partial
evaluation for functional dataflow analysis is really trivial as long
as there is only a single type: compilation is nothing more than
evaluating the graph while adding postponed semantics to the
code. What makes it hard is presence of higher order constructs. I'd
like to get a handle on this.. move it from the philo level to
concrete code.. Is it all the same thing? Is partial evaluation REALLY
better viewed from a compositional pov, as an intermediate form to get
the evaluation right, and then to transform it back to a graph for
optimizing the register allocation / sequencing? That can't be the
case really, since both are easily related to each other. Probably i'm
forgetting about associativity here.. )




[Reply][About]
[<<][staapl][>>][..]