Difference between revisions of "Talk:Chart research"

From PublicWiki
Jump to: navigation, search
m (Join)
Line 14: Line 14:
 
==Join==
 
==Join==
 
I don't know who Jack and Moriarty are, but I gather you're working with the architecture group.  Just a note: to me Charts (once you get past the very curious syntax) looks a lot like a subset of the Join Calculus.  [[User:Keunwoo|Keunwoo]] 16:08, 8 March 2006 (PST)
 
I don't know who Jack and Moriarty are, but I gather you're working with the architecture group.  Just a note: to me Charts (once you get past the very curious syntax) looks a lot like a subset of the Join Calculus.  [[User:Keunwoo|Keunwoo]] 16:08, 8 March 2006 (PST)
 +
 +
Closely related to the join calculus.  Flow is limited (channels are always fully instantiated locally) but the purpose of this is twofold: to make charts into components that can safely be manipulated by other constructs (mainly for reflection); and to remove the implicit notion that a chart has to represent a dataflow system.  Because a node's output is a function of its inputs you can write a chart just as well in a functional notation.  Our notation has to express the relationship to the dataflow systems (join and pi calculi) and functional systems (lambda), and for a temporary notation it seems to do fine.  --[[User:Moriarty|Joshua]] 16:50, 8 March 2006 (PST)

Revision as of 00:50, 9 March 2006

(1)Must the graph be acyclic? It doesn't seem like that is necessary. I believe that we are looking for reducible graphs. I don't exactly know yet what that all implies, but I do know that allows for certain types of cycles. --Jack 22:11, 10 December 2005 (PST)

(2)What other meta-models are we attempts to deal with besides computation? --Jack 22:11, 10 December 2005 (PST)

(2.1) Hmm. I don't think I meant it like that. I think I meant that it's not just about a certain architecture (as many paradigms try to imply). We are trying to come up with a computational model. This is why we are using a wiki. I will fix it.

(3) We should make a goals/challengs/ideas/restrictions/thoughts/worries page. (done)

(4) Architecture Description Language Somewhat related, though I have not yet read their paper.

Join

I don't know who Jack and Moriarty are, but I gather you're working with the architecture group. Just a note: to me Charts (once you get past the very curious syntax) looks a lot like a subset of the Join Calculus. Keunwoo 16:08, 8 March 2006 (PST)

Closely related to the join calculus. Flow is limited (channels are always fully instantiated locally) but the purpose of this is twofold: to make charts into components that can safely be manipulated by other constructs (mainly for reflection); and to remove the implicit notion that a chart has to represent a dataflow system. Because a node's output is a function of its inputs you can write a chart just as well in a functional notation. Our notation has to express the relationship to the dataflow systems (join and pi calculi) and functional systems (lambda), and for a temporary notation it seems to do fine. --Joshua 16:50, 8 March 2006 (PST)