Recommended Literature

1. Recommended Literature • There are no prescribed texts. • “Visual Programming with Prograph CPX” • by Scott B. Steinman and Kevin G. Carver, • Manning Publications/Prentice Hall, ISBN 0134411633 • Is recommended (the only available text on Prograph), but not strictly required. • Other literature (research papers) will be referenced throughout the subject • and are generally available on the web. • For the project you should read the following paper, which will be available on-line. • Simulating Graphs as Physical Systems, A. Frick, G. Sander and K. Wang in • Dr. Dobbs Journal, August 1999 • R. Davidson and D. Harel. Drawing Graphs Nicely Using Simulated Annealing. • ACM Transactions on Graphics, 15(4):301-331, October 1996. • Fruchtermann, T. M. J. and Reingold, E. M. (1991). Graph drawing by force • -directed placement. Software Practice and Experience, 21(11):1129--1164.

2. Further Literature Visual Programming is an active research area, but not a well-established subject. This has the unfortunate consequence that there are no general textbooks available that cover the contents of the lecture. Useful resources are the following: - “Visual Programming with Prograph CPX” by Scott B. Steinman and Kevin G. Carver, Manning Publications/Prentice Hall, ISBN 0134411633 (useful, but not strictly required, because Prograph comes with extensive documentation) - Ephraim P. Glinert, editor. Visual Programming Environments: Paradigms and Systems (Vol 1) and Visual Programming Environments: Applications and Issues(Vol 2), IEEE Computer Society Press, 1990 - The proceedings of the conference series “IEEE Symposium on Visual Languages” - The journal “Journal of Visual Languages and Computing” by Academic Press - The lecture material often gives web-links for specific program systems. at these pages you do not only find the systems and their implementations, but also research papers on the systems.

3. Paradigms of Visual Programming • Dataflow Programming • Nodes describe operations, • arrows the flow of information between • these nodes • Rule-based visual Programming • Basis: Logical Implication • “if fact A holds, then fact B holds” • or Production-system like action rules • “if situation A is found, then do action B” • Functional Programming • Basis: mathematical functions (without side-effects) • a program has the form • f1(f2(f3(... (input) ...)))

4. Data Flow Programs • Visual data-flow programming is the most common visual programming paradigm. • We use Prograph CPX as described in • “Visual Programming with Prograph CPX” • by Scott B. Steinman and Kevin G. Carver, • Manning Publications/Prentice Hall, ISBN 0134411633 • “The Power of Prograph CPX” • by D. Shafer, • The Reader Network, 1994. • (out of print) • More information on (as well as the implementations of) Prograph can be found at • http://www.pictorius.com/prograph.html • Prograph CPX runs on Windows and will be available in the CA Labs.

5. Functional Visual Programming CLARITY (http://www.clarity-support.com/) Clarity is a complete functional language in the style of ML original motivation for Clarity was work on the functional database model An important aspect is the incremental, interactive design of programs The claim of the Clarity designers is that visualization introduces an additional conceptual level.

6. Rule-based Visual Programming • Universal Programming Paradigms • Visual Logic Programming (Prolog etc.) • Visual Constraint Programming (Pictorial Janus, Toontalk) • Programming Paradigms for Programming with Pictures, • particularly visual Simulations • Production-system languages pixel-based: BitPict high-level image based: Agentsheets (http://www.agentsheets.com) Visual production systems generally have the form SearchPicture => Modification This is interpreted as “if you find the picture SearchPicture in the current picture then apply the right-hand side modification to the current picture” • Can be used for simplified “Programming by Example”

7. Visual Production Systems • used for implementing computations that directly operate on pictures. • Mainly experimental research vehicle. Only real-world application: Visual Simulation / Creating AnimationExample: • BITPICT, a system for reasoning purely by diagram transformation. • (For more information visit http://www.si.umich.edu/~furnas/) The given rules (right) count the number of trees in a “tangled forest” by reducing each tree to a single dot.

8. LabView Another visual data flow language, in principle relatively similar to Prograph CPX is Labview by National Instruments. Labview is a commercial product which is (surprisingly enough) targeted for use in the laboratory. It has a string emphasis on data acquisition and instrument control and is therefore equipped with large interface libraries and Labview can be regarded as the most successful example of the commercial industrial application of universal visual programming languages. We will not discuss this system in detail here and only give the flavor with some brief example pictures. More Information can be found at: http://www.ni.com/labview/ or in “LabVIEW Graphical Programming: Practical Applications in Instrumentation and Control” by Johnson Gary W., Gary W. Johnson. McGraw-Hill, 1997. and many other books on LabView...

9. To give an idea of what programming in Labview is like, we run through a tiny example of a trivial Labview program that repeatedly acquires a temperature reading and plots the corresponding graph.

16. Examples of LabView Interfaces (I)

17. Examples of LabView Interfaces (II)

18. Data Flow Programs • Visual data-flow programming is the most common visual programming paradigm. • We use Prograph CPX as described in • “Visual Programming with Prograph CPX” • by Scott B. Steinman and Kevin G. Carver, • Manning Publications/Prentice Hall, ISBN 0134411633 • “The Power of Prograph CPX” • by D. Shafer, • The Reader Network, 1994. • (out of print) • More information on (as well as the implementations of) Prograph can be found at • http://www.pictorius.com/prograph.html

19. Visual Data Flow: Prograph • - programming based on graph structures • - data flows along the links and is • processed at the nodes • DFP has no concept of variables! • DFP typically has a procedural reading • DFP uses explicit control constructs • DFP is in some ways conceptually close to functional programming. • It is, however, typically weakly typed and does not use pattern matching. • - DFP is close to classical (procedural) programming, • because we need to think about the execution mechanism • - practically visual DFPL are the best developed VPLs with IDEs that • contain compiler, interface builder, object-oriented extensions, • system-level interfaces and multi-platform support • - visual DFPLs are the only universal VPLs with many industrial applications • (Labview)

20. Typing in Prograph • Weak Typing • Runtime-typecheck only • Basic types: • Boolean • Integer • Real • String • List • Lists are homogeneous • Data Objects are immutable • I.e. once an data element has been created it cannot be changed. • It can only be replaced by a different new object in the data flow. • All “clean” string/list operations generate copies instead of mutating values. • This is not a property of Prograph, but generally of DFP • And a consequence of the fact that there is no concept of variables. • An exception to this rule are instances in object-oriented DFP. • Garbage Collection is performed automatically (reference counting: watch cycles)

21. Control Constructs - Control in Prograph is explicit. - Each method can have multiple cases. - Each case is depicted in a separate window with input bar (top) and output bar (bottom). - To select the applicable method, no parameter matching is involved: Control always starts in the first case and must explicitly be passed on. - Control structures in Prograph come in two forms: Case Control and Iteration Control (called “multiplexing”). - Example: Determining the sign of a number sign(x)=abs(x)

22. Case Control - Case switching is achieved by attaching a “Control” to a “Test”. (Generally, controls can be attached to any operation). - The possible Controls are: - “Next Case” switches to the next method case, - “Continue” continues normal execution upon failure of the test (negation) - The other controls are for loop execution and “failed execution” - Two types of tests are available: built-in operations and constant comparison

23. Failure Control - In Prograph every operation has three possible outcomes: success, failure or it raises an error - An operation is by default successful, except for built-in boolean operations like arithmetic tests. - Failure propagates to the calling function. - Using an explicit fail control makes it possible to let an operation fail. - Like with a built-in test, the calling method can use a control to make a control flow decision based on the result. - Example:Case Bignum 1:1 uses an explicit failure control if comparison fails.

24. Tests with Return Value • Instead of using failure control all built-in tests can also be used in the • “classical way” with a return value: • This will show “True”/”False” • depending on the input. • As Failure is a better way to control execution, • this is rarely used except for if needed in • boolean formulas:

25. Loop Multiplexes - Loops are controlled by Annotations. - Repeat annotates a method to simply execute repeatedly until a Fail, Terminate or Finish Control is executed - List is used for iterating over the elements of a list (much like “map”) - Loop annotation an operation to execute repeatedly, while one of the output “terminals” (values) is “looped back” to one of the input (roots) - Example of a Repeat control (stacked box):

26. List Multiplexing - List annotation can be used on input and output. On the input it causes the method to be repeated for each list element on the output it causes the successive outputs to be collected into a list (an example appears later in Quicksort).

27. Multiplex Control - Terminate, Finish and Fail can be used to control iterated (Multiplex) methods - Terminate stops the multiplex immediately -> The last input value is used as the output value (i.e. the output of the last successful iteration) - Finish stops the multiplex, but lets the the current iteration finish - Fail passes failure to the calling method. Example: “find a C?” shows (C S E) 2 for terminate and (S E) 3 for finish

28. Summary of Controls - All controls can be triggered “on success” (check mark) or “on failure” (cross) of the triggering condition. - With combinations of Controls and Annotations all possible control structures can easily be implemented.

29. Synchronization • - Finally, we need a way to synchronize operations, i.e. to control the order of • execution, since there is no implicit order of operations in a data-flow graph • except for the order that is imposed by the fact that data values must be • available, before they can be processed. • - However, since side effects like input/output or setting variables may require • more precise control over the execution order, we need an explicit control. • - This is given by the so-called “Synchro” edges which force the linked operations • to be executed in the indicated order. • - Example: Open, Write-to and close a file • in the required order of operations • Compare this to the evaluation order of functions, eg. • z := f(g(x)) + h(y). • In proedural programming language, the order of evaluation is known. • In other programming paradigms, it is often not known.

30. Injects Injects allow to determine the Operation to be executed at run-time, ie To write dynamic code. This is in spirit similar to the “eval” and “apply” operations in eg. LISP. Injects “inject” the name for an operation into a dummy node:

31. Recursion - As another means of control, recursion can, of course, be used in the usual way by letting a method call itself. - Example: Towers of Hanoi

32. Towers of Hanoi • Imagine the following setup: • three sticks (a, b, c) on which disks of varying size can be stacked. • In the beginning all disks are on stick “a”. The task is to move all disks to • stick “c” with the following restrictions: • only one disc may be moved at a time • a larger disk may never be on top of a smaller disk • at the end of each move all disks must be on the sticks. • This can be achieved by the following algorithm: • Solve(N, Src, Aux, Dst) • if N is 0 exit • Solve(N-1, Src, Dst, Aux) • Move from Src to Dst • Solve(N-1, Aux, Src, Dst)

33. Towers of Hanoi

34. Example: Quicksort One of the fastest sorting methods. (see any textbook on data structures and algorithms for details). • algorithm quicksort(List L) • begin • if length(L)=1 then return L; • else if “all elements in L identical” return L; • else begin • select non-minimal element x from L; • L1 := list of all elements y in L with y < x; • L2 := list of all elements y in L with y >= x; • S1 := quicksort(L1); • S2 := quicksort(L2); • return concatenate(S1, S2); • end; • end.

35. Quicksort in Prograph A complex example of code that uses list annotations, controls annotations and recursion

36. Partitioning We make use of a special annotation type that we have not yet seen: the Partition annotation: It iterates over a list to check its elements for some condition (here if they are larger than the pivot values) and splits the input list into to disjoint output lists: one with the values satisfying the test the other with those for which the test failed.

37. Helper Methods Finally, we need a method to join the partial results together. We use the built-in “(join)” method, as well as the built-in “pack” which packs its input elements into a list.

38. Object Orientation in Prograph Prograph includes an object-oriented language extension. (The examples up to here were so-called universal methods which do not make use of these extensions). Visual Object-oriented programming is fully supported with visual definition of class hierarchies template-based class schema and instance editors Prograph supports static binding (the applicable method is determined at compile time) as well as late binding (the applicable method is determined dynamically at run time). The choice is explicitly made by the programmer for each call. Like many other modern object-oriented languages, Prograph also supports “Reflection” or “Introspection”, i.e. a program can analyze its classes and instances, e.g. get a list of all class names, a list of attribute or method definitions for a particular class etc. We will treat object-orientation is a separate lecture.

39. Object Orientation I I Class Hierarchy Editor Basic OO-Operations Class Schema Editor

40. System-Level Interface - As a system-level interface, a whole set of “external” operations is provided. - These operations work in the same way as internal operations, but they call external definitions (system libraries, toolboxes, DLLs, etc.) External constants and matches: External get Field, set field and address External Method:

41. Interactive Environment - Prograph uses a two-part interactive environment with an interpreter and an incremental compiler. - This allows for complete stand-alone applications can be compiled. - At the same time, fully interactive debugging and run-time inspection of all objects / properties / values on the stack is made possible. - In the interactive debugger it is possible to change object properties, class definitions and method definitions even within an interrupted method before resuming operation (with some limitations). This is very similar to the programming environments of Lisp systems. - Automatic program animation is available for debugging purposes (this works by fluently executing single execution steps, a snapshot of a Hanoi execution is displayed on the next page. blue is used for “finished”, red for “executing” and green for “waiting”)

42. Animated Debugging

43. Interface Builder - like any proper contemporary programming environment, Prograph CPX comprises an interactive interface builder in which GUIs can be constructed without explicitly programming the layout. Like in most other programming languages, the functionality / behavior is later defined by attaching action methods to the interface elements .