Talk:Chart research

From PublicWiki
Revision as of 00:26, 10 March 2006 by Keunwoo (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

(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)

(And on second thought, a much more practical reason is that it implies a sort of strong modularity that would do well for open source and academic projects and can play well with existing languages. --Joshua 16:52, 8 March 2006 (PST) )

Well, one can express functions, whether asynchronous or synchronous, using relatively simple syntactic sugar on top of either the Join or pi calculi. See JoCaml and Pict. Also, you say that "channels are always fully instantiated locally" --- I understand this to mean that all well-formed terms in Charts are closed (i.e., they do not have free channel names)? The pi-calculus has a scope operator for channel names, so the scope of names can be controlled. It would probably be illuminating to examine how Charts would be encoded in a pi calculus augmented with asynchronous join-patterns, or conversely a join calculus with a better scope operator. Keunwoo 16:26, 9 March 2006 (PST)