Concepts+Techniques+and+Models+of+Computer+Programming_Part13

Concepts+Techniques+and+Models+of+Computer+Programming_Part13

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 318 Declarative Concurrency {P1 ...} {P2 ...} end proc {P3 ...} ... {P2 ...} {P3 ...} end fun {Count} @Ctr end in ´ export ´ (p1:P1 p2:P2 p3:P3 count:Count) end In this case, the component interface has one extra function, Count , and the interfaces to P1 , P2 , and P3 are unchanged. The calling module has no book- keeping to do whatsoever. The count is automatically initialized to zero when the component is instantiated. The calling module can call Count at any time to get the current value of the count. The calling module can also ignore Count completely, if it likes, in which case the component has exactly the same behavior as before (except for a very slight difference in performance). Figure 4.33 compares the two approaches. The figure shows the call graph of a program with a component Main that calls subcomponent SC . A call graph is a directed graph where each node represents a procedure and there is an edge from each procedure to the procedures it calls. In Figure 4.33, SC is called from three places in the main component. Now let us instrument SC . In the declarative approach (at left), an accumulator has to be added to each procedure on the path from Main to P1 . In the stateful approach (at right), the only changes are the extra operation Count and the body of P1 . In both cases, the changes are shown with thick lines. Let us compare the two approaches: • The declarative approach is not modular with respect to instrumenting P1 , because every procedure definition and call on the path from Main to P1 needs two extra arguments. The interfaces to P1 , P2 , and P3 are all changed. This means that other components calling SC have to be changed too. • The stateful approach is modular because the cell is mentioned only where it is needed, in the initialization of SC and in P1 . In particular, the interfaces to P1 , P2 , and P3 , remain the same in the stateful approach. Since the extra operation Count can be ignored, other components calling SC do not have to be changed. • The declarative approach is slower because it does much extra argument passing. All procedures are slowed down for the sake of one. The stateful approach is efficient; it only spends time when necessary. Which approach is simpler: the first or the second? The first has a simpler model but a more complex program. The second has a more complex model but a Copyright c 2001-3 by P. Van Roy and S. Haridi. All rights reserved. 4.7 Limitations and extensions of declarative programming 319 Cli ent 1 Client 2 Server ? OutS2 OutS1 InS Figure 4.34: How can two clients send to the same server? They cannot! simpler program. In our view, the declarative approach is not natural. Because it is modular, the stateful approach is clearly the simplest overall....
View Full Document

Page1 / 30

Concepts+Techniques+and+Models+of+Computer+Programming_Part13

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online