An Alternative Form of Computer Programming
Hayashi, Tsunetoshi Department of Computer Science
Ritsumeikan University
currently on leave to
Department of Computer Science University of Canterbury
Christchurch New Zealand
Abstract
This paper is about an alternative method to present computer programs. Computer programs are usually written in a programming language framework, and made into existence as a file of text format data. This method was initially developed at the start of computer programming, and used long since then until now. It seems, however, it shows its age recently, since amount of programs to be developed on and for contem- porary computing systems grows so huge that its abstraction level is insufficient to support them.
Here we will present alternative method to present computing mechanism for a computer. The description is based on Data Flow Programming Scheme, and uses graphical representation with “point and click” graphical user interface editing. And some additional topics on improvement of the method, concerned with the program structuring, are discussed.
A short outline of concrete design and compiler algorithm is also given as a con- clusion.
1 Computer Programming Up To Now
1.1 Programs Are Written as Text Data
Any textbook on Compiler Construction describes a compiler as a program to convert a source program into an object program. It carries out, on a source program, lexical analysis, parsing, and code generation. The definitions of classes of these programs seem very trivial. An object program is a binary executable program in a format determined by the Operating System on which it runs, which is also a file also defined by the OS. The definition is very clear and concrete.
On the other hand, the definition of source program seems a little bit blurred. Is it a file containing a text data with specific syntax? Is it a printed document texts with some styles? For a compiler, the definition is very clear, a text data file with specific syntax. As for Programming Language, the definition is not so clear for some languages.
Algol 60, Algol 68, Pascal, Ada and likes distinguish printed source programs from text
data files. The authentic programs are in printed format where reserved words are written
in bold style, user defined words (identifiers) are in italic and operators are in normal style. See Knuth’s elaborate volumes of published TEX programs. These languages must have translation schemes from printed program to text data format. More conventional program languages such as Fortran, Cobol, PL/I, C, C++ and so on do not have these separate definitions.
Anyway, if a source program is to be compiled, it must be made into a text data format file. This is a historically correct from the beginning of computer industry. The very first programming language, Fortran, as well as assembly language (symbolic programming in those times) needs to be punched into a stack of cards using IBM 026 puncher, or a roll of paper tape, and fed into a computer. There were no other means to denote such a symbolic data. Source programs are kept and stored in these formats, using card stacks, or later files in magnet tape volumes.
Then, operating systems made some progress to support the time sharing job schedul- ing, source programs may be entered by way of terminal time sharing session and kept in a file of central computer. First, using a line editor on teletypewriter, and later succeeded by a full screen text editor on a centrally controlled full screen text display terminal such as IBM 3270, or DEC VT-100. A text format data is only useful media to denote a source program of any programming language during these times and until now.
Text data format is an easy to create and easy to maintain format. It taxes neither excessive processing power nor redundant space to store. It is also very easy to edit text format data in punched card and paper tape, the procedure is intuitive as one may know. It is not so difficult to edit electronically stored text format data using full screen character oriented telecommunication terminal. The editor program only need to know the current viewing position in the character string denoting the text data. The program can designate the cursor position in the display using the position in the character string.
It is ironical, however, that editing text data in a modern graphic oriented environment is rather a difficult task. An editor needs to convert, from time to time, cursor’s position in pixel coordinate to and from line and character position by using font metric database, and this requires much tedious calculation. So far the text data is the choice of denoting programming languages.
And this is the reason why a compiler construction project needs a programmer to concentrate his/her efforts into non-essential parts of the program. As a source program is in the text format, a compiler has to cut out elements such as reserved words, identifiers, and operators consisting a program from continuous stream of characters. Then it has to reconstruct the formation of these elements into a meaningful structure, such as an abstract program. The most essential part of a compiler, the code generation, which translate this structure into a series of executable instructions, is an appendix to the previous parts. As you know, some software tools for these processes are available and sometimes a compiler employs them, however, a larger part has to be still hand coded, still you must supply semantic processing codes to a yacc program.
Should this hold for the next generation of programming languages?
If you can write, or in better words, design a program without reverting to the text
format and enter a meaningful structure of a program directly into a compiler, you do not
need to develop an elaborate and sophisticated syntax parsing algorithm, instead you can
concentrate on developing useful code generation algorithm. With the advance of recent
graphical user interface technology, this approach for programming becomes increasingly
feasible.
1.2 Major Programming Languages Abstract Von Neumann Architec- ture
The first electronic computer was, in essence, a programmable calculator. It was pro- grammed using a detachable patch board. Codes connecting the terminals of a board denote a program. The formation of codes tells how a data should be transmitted from the accumulator to the adder to the register. And one should keep in mind that this is the first method of denoting computing mechanism.
Then, Von Neumann proposed the so-called Von Neumann architecture of computing machine, also known as stored program computer architecture, where, any data to be calculated upon are stored in the predesignated memory area along with the instructions which determine the movement of these data. Each memory locations are numbered sequentially so that each memory cell could be independently read out and written in.
The memory could be viewed as an array of numbered uniform cells.
There are several distinctively functional places, where actual calculation can be per- formed. Depending on the machine model, these places are called an accumulator, reg- ister, or in some cases memory itself. For doing complex calculation, the data stored in the memory should be moved around from memory cells to the register to memory cells.
An instruction designates the movement and calculation executed. The instructions are also data stored in the memory cells, and encode in its bit pattern the operation and operands upon which the operation will be executed. A register usually called program counter, or sequence register, keeps the position of the currently executing instruction. By design of the architecture, this register is automatically incremented after an instruction is executed, thus enabling consecutive instructions to be executed continually, without stopping. Certain instructions are provided to rewrite program counter itself from a value designated in the instruction, so that another section of instructions can be a candidate to run.
This is a very simple and, at the same time, powerful architecture. It could be made to do almost everything if the sequence of instructions, a program, could be constructed.
Compared with the patch board, however, a inferior feature reveals itself, that computation will be done one step at a time. In the patch board model, several data transfers could occur in parallel to each other. And the premise that a program could be constructed seems to imply more difficult problems.
If one wishes to do a meaningful task on a computer, one has to write a program, or obtain one from somewhere. Anyway, someone has to write a program. In the above case, a programmer has to construct a program as a sequence of bit patterns. To do this effectively, one has to memorize every bit pattern of instructions, and place them in a meaningful sequence. This is an formidably hard task to accomplish if the length of a sequence grows more than a few hundreds. And this is where text data kicks in into the scene.
An instruction can be denoted by a more symbolic, more easy to remember, text form instead of a bit pattern. For example, ADD and SUB for 010000 and 010001. This can be described that symbolic form has higher level of abstraction than a bit pattern. The symbolic form can be reduced to bit pattern by a transforming program, called assembler.
The principle is that tedious tasks should be done by a machine that is designed to do
such things. The assembler programming, called symbolic programming at the time,
hugely increased the productivity of programmers, so that Operating Systems (OS) and
Compilers as well as assemblers themselves are realized into existence.
Text data is essentially of sequential, consecutive form. It need be interpreted from head to tail. If one reads text from tail to head, it is completely indiscernible. And this attribute is the most suited to the sequential nature of Von Neumann architecture, where programs share the same attribute. They are made to go along with each other, hands in hands. This is not much changed with the advance of higher level languages.
In case of patch board model of computation, this does not hold. One can express patch board connection as a connection table as a text format data, this will be quite indecipherable for a human. A simple block diagram, or a circuit diagram, will be sufficient for denoting the computation it implies. Text format is useless for this kind of computation model.
1.3 Higher Abstraction Level Means More Productivity, More Amount of Codes
The one to one correspondence between symbolic instructions and machine instructions can support high performance computation, where a program extracts maximum perfor- mance out of a machine. This is a necessity for, for example, developing an operating system, where existing resource should be utilized as much as possible. However, as with the task oriented computation, the abstraction level of symbolic programming is consid- ered insufficient. Therefore higher level programming languages are invented and become in wide use. These languages, with a few exception, belong to a class of so-called Algorith- mic Languages. To name a few: Fortran, Cobol, Algol60, Pascal, Algol68, PL/I, Ada, C, C++, Basic, BCPL, and the list is hard to be exhausted. They all share common grounds.
The elements constituting an algorithmic language are variables, expressions, assign- ments, control structures, and functional groupings. They are all, in some degree, ab- straction of the Von Neumann architecture. Variables are abstraction of memory cells and registers. Assignments are abstraction of memory store operations. Control struc- tures are abstraction of unconditional and conditional branch operations. Expressions are descended from mathematical concepts, and with assignments, the working engine of algorithmic languages. Later, block structures and scope rules became their inseparable parts, and they can be viewed as higher abstraction of Von Neumann memory cells.
Usually a statement of a higher level language generates several machine instructions, the level of abstraction of a compiler is higher than that of an assembler in terms of such instruction count. And this fact enhances the productivity of programmers much further.
Higher level languages makes it possible for a programmer to write a few hundred thousand codes. Sophisticated operating systems with graphical user interface are actually written in this way, where millions of instructions are embedded. However, for the next generation computer system, where hundreds of millions of instructions are supposed to be required, a question is inevitable whether the abstraction level of current programming languages is sufficiently high, and whether the sequential, pin-point execution model of Von Neumann architecture is adequate.
1.4 Is Current Level of Abstraction Sufficient for Future Generation Programming?
The advent of graphical user interface and its incorporation into operating systems are
unmistakably the most notable progress of computing systems. This helps computing
systems to be daily appliances in wide use. At the same time, their cost is much reduced
and their performance is unimaginably increased. A professional workstation a decade ago has much less computing power than a today’s home computer or even a game console does. A large amount of codes are thrown into application software products to make them user friendly exploiting underlying computing power. This situation will not be changed at least a decade, and that is the rationale of the above question. Is the abstraction level of algorithmic languages are sufficient for such amount of codes? Is algorithmic languages abstracting Von Neumann architecture computing adequate for graphical user interface application? Does text format denotation of programs endure programming of next decade?
In a graphical user interface environment, an application program is not allowed to assume active role in doing its functions, instead it must assume passive role; it can only perform its function as a response to user’s action. Users should be permitted to do anything in any order, however it is irrational and erroneous. Users may click a button, select a menu, type a key, or move mouse around, in any order. An application program must respond to each action correctly without reserve, or may return error messages.
Computation will be carried out as results of responses.
This passive principle is very different from that of old command line computing days, where an application program assumes active role. An application program, once invoked, obtains parameters from command line, inquires a user additional parameters, and runs by itself without interacting with a user. This active role model can be regarded as an implicit appearance of Von Neumann architecture, where a processor basically runs by itself without intervention from outside.
To compensate the discrepancy between the passive role of an application and its active role in the architecture, a technique called event driven programming has been developed, where an application program runs an outermost loop in which it senses the action of a user, and then dispatches corresponding functions. Note that this construction is the same as that of an interpreter/emulator program, a Von Neumann architecture machine has the power to do anything through emulation. Object-oriented programming methodology is also of help to effectively realizing the passive role programs in the active role architec- ture, where a larger part of program is written as methods which assume passive role.
Therefore it is, in principle, possible to write graphical user interface applications in an algorithmic language, however, the written codes tend to be tedious and cumbersome, fail to reflect their logical structure. A completely different, alternative model of computing that intuitively supports graphical user interface application is necessary and should be better developed for future programming.
2 Alternative Ways of Program Representation
2.1 Some Other Approaches to Programming Concepts
Consider push button controlled electrical appliances, for example tape recorders, where
each button is provided with separate dedicated circuit to realize its function. These
circuits are connected by relays and actuators and lamps and motors that will perform
the actual functions, start tape, engage heads, stop tape etc. Relays need to do some logical
computations for smooth operation. In a sense, abstraction of these electrical machines
may denote the graphical user environment application programs. It is regrettable that
current implementation of push button control does not obey this principle, instead an
embedded microprocessor is always scanning the button status, and if it senses an action,
it responds to that action. This is, again, an interpretive realization of action-response framework.
Another model is now virtually obsolete HyperCard Programming Environment de- veloped by Apple Computer. It employs card stack metaphor for organizing various in- formation. Each card may contain objects such as buttons, texts, pictures and sounds, and these objects may be associated with scripts in Hyper Talk, which define responses executed to user’s action. If a user takes an action on one of these objects, associated script will be invoked, to open another card, to shift to another card, or to close a card and so on. This principle is the same as that of above electrical push button model.
In these models, users’ actions on the interface and responses invoked by them are more directly coupled than that of event driven programming. To pursuit further to this end, more intuitive description of responses had better be exploited, that is based on the circuit diagram metaphor. Responses need not be described in an algorithmic programming language.
2.2 Another Way to Describe Computation — Data Flow Language A few decades ago, Jack B Dennis proposed Data Flow Programming Scheme. In his programming scheme, computation mechanism is denoted by a network consisting of arcs and nodes. The network acts like a Petri net. Source and computed values moves along arcs as tokens. Each node performs associated mathematical/logical/other operations if all of operands are available in its incoming arcs. The resulting values are sent out to outgoing arcs. A gate node is provided for conditional operation. Repetition construction can be trivially constructed by circular arcs. In a sense, this is an abstraction of electric/electronic circuits, like as Petri nets itself is an instrument for designing asynchronous logic circuit.
Arcs may be branched out and merged as needed. This implies the values traveling on arcs may be duplicated arbitrarily without restriction. This is by no means a problem with simple value, but may be some problems with complex values. Among merging arcs, at most one arc should carry a value, or else the result is undefined.
Dennis also proposed that the data on arcs need not be simple integer/real/logical values, instead they may be complex objects, so-called Vienna Objects. With respect to today’s object-oriented programming method, this is a very excellent prediction.
As stated above, Data Flow Programming Scheme is essentially grahical-oriented.
Therefore, it potentially does higher level of abstraction, as graphical objects can carry larger amount of information than that of text counter parts. This is the most important reason for Data Flow Programming Scheme to be pursued as the means of programming of future.
In Data Flow Programming Scheme, unlike an algorithmic language, the construction is static and time independent. Therefore properties associated with each node and arc may be easily calculated, thus enabling the verification far easier than that of a program in an algorithmic language. In an algorithmic language, the construction is dynamic and time dependent. It is very difficult to associate properties to variables which vary with time.
This is one of the outstanding characteristics of the Data Flow Programming Scheme.
The next figure shows an example program of Data Flow Programming Scheme. Al-
though the presentation is slightly different from that of original proposal, this example
can well convey the principle of Data Flow Programming Scheme. This simple program
calculate a factorial of input integer. Single boundary circles are operators, double bound-
ary ones are gates to control the flow of data. Each operator has its input on its upper
IN
1
>1
−1
×
>1
OUT GATE
F
GATE
T F
GATE
T
>1
Figure 1: Data Flow Program Example–1
side, while output in its lower side. A gate has also its Boolean input on its side.
Interpretation of programs denoted in this syntax is as follows. Data values are supplied to an operator from upper side, and result values will be dispatched from its lower side.
When data values are ready to all of input, an operator will trigger itself and perform its operation. Then the resulting value is put to its output. Only single data value (token) can travel on an arc at a time. There may be alternative interpretation by which values may form a queue in an arc, but here we will stick to the former interpretation for simplicity.
Constant is considered as an operator with only output. The “IN” operator, denoting input for program as a whole, also has only output which serves as data source. The
“OUT” operator, denoting output for the whole program, has only input which serves as data sink. A Gate switches its input to one of its outputs depending on the Boolean side input value.
As you may notice, value is duplicated on branching arcs. This implies operators connected to branching arcs may carry out their function in parallel. In essence, Data Flow Programming Scheme models asynchronous, distributed, parallel computation. Once, it was supposed Data Flow Programming Scheme might liberate programs from the curse of Von Neumann architecture.
The level of programming of this example program is equivalent to that of flow chart
IN
1
>1
−1
×
OUT GATE
F
GATE
T
F F
denotation of an algorithmic language, exploiting explicit loop for repeated calculation.
The former shows the flow of data while the latter shows the flow of control.
The following is another example of factorial calculator with slightly different flavor.
Assuming some naming and grouping convention, this example uses recursion instead of explicit loop. Compare with a program in functional programming scheme such as Lisp, you may find some similarity among them.
Figure 2: Data Flow Program Example–2
The Data Flow Programming Scheme, however excellent it may be, did not produce a popular programming language. It may be supposed the major reason for this is that it lacks adequate text format representation. Its denotation is essentially graphics oriented, so if a data flow program is written in a text format, it becomes quite indiscernible, just like as a circuit connection table is intuitively more unrecognizable than a circuit diagram.
At the time of proposal, graphical user interface is not advanced or popular as is now. In
addition, it also lacked structuring facility in itself. It did not provide grouping facility,
nor control structure, nor selection, nor repetition structure in itself. These functions may
be realized using explicit looping arcs and Boolean operators and gates. In a sense, the
Data Flow Programming Scheme, at the time of proposal, is in nonstructural programming
framework.
In order to exploit Data Flow Programming Scheme in its full form, it should be enhanced with some graphical user interface editing and program structuring functions.
2.3 An Example — Prograph CPX
It is known to few of the Computer Science circles that a programming language based on Data Flow Programming Scheme with graphical user interface has been actually developed once as a commercial product and publicized. Pictorius Inc. of Canada has developed an application development environment, called Prograph, based on the Data Flow Pro- gramming Scheme, which runs on the Macintosh computers made by Apple Computer Inc. Prograph has several versions, one is Prograph Classic generously published free of charge; another is Prograph CPX, a commercial product. Prograph Classic is supposed to run under older version of Macintosh OS.
Prograph had some enhancements and extensions to the original proposed scheme.
These enhancements are:
• Object-oriented programming support; class, inheritance, instance variable, instan- ciation, method, and messaging are implemented
• Methods are denoted by flow graph and editable using graphical user interface
• Expression is used instead of simple operator
• Strong grouping and naming facility are provided; any connected part can be grouped into a named operator
• Repetition structure is implied by agglomerated data flowing on arcs
• Conditional flow with tagged arcs
• Special arc type for synchronization is provided
• Standard application framework class library is implemented
These enhancement makes Prograph a very ideal and desirable application development environment for Macintosh OS. It is regrettable, however, Prograph did not become very popular development tool among Macintosh developers. Recently, Pictorius does not seem to promote the programming language very enthusiastically.
3 A Little Bit of Diversion to Intermediate Considerations
3.1 Programs May Be Written in Other Than Text Data
Before plunging into the world of Data Flow Programming Scheme, we had better explore
some alternative representation of traditional algorithmic programming languages other
than text format. From the beginning of programming, programs are documented in flow
chart. And this documentation method has not made much progress until now, except
for Knuth’s Web Language, or literated programming (do not confuse this Web language
with WWW page description language, which is called HTML). Flow chart itself is not a
respectable method of program description from the current point of view on structured
programming.
Statement
Statement
Statement
Conditional
Statement
Statement T
F
Conditional Statement
There are alternative proposals to denote some of programming aspects in structured graphical form, for example, Ben-Schneidermann chart is one such a proposal. Here we in- troduce PAD (Problem Analysis Diagram) proposed by Futamura, where control structure is represented by some graphic objects. Programs in PAD chart look like flags hanging from a mast.
(a) sequence
(b) conditional (c) repetition
Figure 3: PAD Chart
To our disappointment, this approach can hardly give support to graphical represen- tation of variable declarations, statements, and expressions. At this level of programming, no graphical representation is adequate, and pieces of programs must be written in text format.
3.2 Graphical Representation May Support Higher Abstraction Level By integrating point and click graphical user interface editing with the above graphical representation of programs, an excellent programming environment may be developed.
Perhaps, a few development systems have been already proposed and written. There might be some commercial products.
In this consolidated approach of programming environment, the compiler may not need process lexical analysis and parsing. The required internal program structure (parsed tree, or abstract program) is already present for graphical editing. Compiler need only utilize the internal structure and elaborate it to generate machine code.
The same approach may also be employed by a compiler compiler program, where
the processor integrates syntax diagram editor and parser generator. In this case, the information required for lexical processing is also already present, not only the parser but lexical processor can be produced at the same time.
Anyway, these graphical representations, rather than the text format, of programs appeal far better to human intuition, and at least this method should be further exploited for the next generation programming environment.
4 A New Language Based on Data Flow Scheme
4.1 Is a New Language Required?
Although we knew a commercial product based on Data Flow Programming Scheme is al- ready present, this necessarily does not make it useless for us to develop another language by ourselves. While Fortran and PL/I are available as commercial products, public do- main programming languages such as algol 60, Pascal, Modula, and C were proposed and developed. Therefore we will make an attempt to design and develop a new programming language based on Data Flow Programming Scheme, and put it in the public domain. For this purpose, we will discuss various aspects of language design concepts based on Data Flow Programming Scheme in the following.
4.2 Values, Classes, Objects, Methods
In Data Flow Programming Scheme, calculated values travel over arcs of the network, every arc must be attributed to a type of values. This is equivalent to strongly typed concept of algorithmic programming languages. Therefore, types of values may be constructed in the same way as that of conventional programming languages.
The elementary value types the new language will handle may be common, conventional ones. They may, for example, include the following:
• enumerated constants – Boolean
– character – user defined
• integer
• real
• string (list of characters)
The last one may be a little bit problematic as an elementary value type. Some aggregation of values may be possible and admitted. Aggregation may include:
• set
• list
• array
A set is an aggregation with no ordering among its members and no duplicated values.
A list is an aggregation with ordered membership. A list may be decomposed into se-
quence of members from head to tail. An array is an aggregation with random accessible
int x
1 2
:= :=
membership. Aggregation of elementary values may be transmitted on an arc as a single value entity. Composition and decomposition operators may be defined for aggregating values. Repetition construction may be defined over members of aggregated values.
Against these simplistic values, it seems easy to define complex value and their types as instances (objects) and classes like as in a conventional object-oriented programming language. This turns out, however, not to be so true. As you have seen, there is no variable and assignment concept in Data Flow Programming Scheme, values are, in a sense, implicitly stored in arcs while they are waiting the destination operator to trigger itself. Therefore instance variables in a class are not compatible with the principles of Data Flow Programming Scheme, some cautious considerations on introducing variables into the language design must be due as this may imply compromise.
If the concept of variables in conventional programming language is carelessly intro- duced into Data Flow Programming Scheme, and named variables, or pointer values, are made to flow on arcs, nothing but confusion will prevail. In Data Flow Programming Scheme, values need to be duplicated unconditionally on a branching arc. This will not be the case with a variable. In the next example, separate assignment operators are placed on both of a branching arc, the semantics of this program segment can be interpreted in several ways.
Figure 4: Variable and Assignment
There may be some simple semantics for variables defined to Data Flow Programming Scheme. For example, when a program is to start, variables will be allocated somewhere on the run time stack, on the premise that the run time stack is available. The so-called l-value (address) is taken as the value of a variable, and this will start to travel on an arc.
If an operator refers to that variable in its input, current r-value (content) of the variable is taken. But this semantics seems not to be a very good solution. See figure 4.
• Is the variable itself will be the same entity subsequent to the branch? In other word, shallow (pointer value) duplicate or deep (content vaue) duplicate?
• What is the content of the variable after the both assignment?
If one assumes the variable subsequent to the branch as separate entities, the interpre- tation becomes simpler, with no conflict, but not much useful. If it is interpreted as the same entity, it will have indefinite value, or two values at the same time.
Therefore we should take some measures to solve these problems. See figure 5.
+1 int x
:=
+1 int x
int x
(a) Conventional denotation (b) Proposed denotation
Figure 5: Denotations of Assignment x := x + 1
• Only value of a variable could be duplicated freely. Or else, if an object need be duplicated at a branch point, an explicit duplicate operator should be exploited.
• Assignment will be done as a terminate operation, in place of output one. This may prevent a variable from being indefinite, but some synchronization construct may be also required.
These conditions may partially solve some problems, but not all of them. Further discussions on this point will be necessary as the programming language design goes into details. Anyway, simple variables are not desirable in Data Flow Programming Scheme.
To represent some complex structure such as trees and queues in a program, program- ming languages have to incorporate mechanisms to describe such class of structure. In a conventional algorithmic language, reference (pointer) data type and structure data type (cartesian product data structure) are exploited for this purpose. In an object-oriented (hybrid) language, class definition (essentially expanded structure data type) is used. In Data Flow Programing Scheme, we may need a similar mechanism. A class definition in Data Flow Programming Scheme may be derived also from conventional class definition.
Here, in figure 6, we will introduce classes using the electronic circuit metaphor. Since a circuit board can have flip-flops and registers to store temporary values, a class may contain several variables, or storage, which can hold values of specified value type. A class is a design template of a circuit board, and an instance (object) is its materialization traveling the network carrying some information. A class has several connector around its periphery. Connectors have their own names to identify themselves. A connector may have several input/output connections (connecting terminals), through which values of specified type are transmitted to/from networks of arcs and operators in a class. Connectors are equivalent to methods in a conventional object-oriented language.
A class has its own name to identify itself. A method may have multiple output
connection if necessary. An instantiation operator associated with the class is used to
make an instance (an object) from a class. Class inheritance and hierarchy concept obey
instance variables
connectors
networks
class
Figure 6: Class Definition
the similar rules employed by any existing object oriented language. But a powerful graphical representation and editing function must be accompanied.
A value of a class can be described using the syntax of Vienna Definition Language Object, as a set of instance variable name and its value pair < name : value >. For example, if we assume complex class has instance variables re and im, a value may be described as { < re : 1 >, < im : 0 > } , where value of variable re is 1, and im is 0 respectively. If an instance variable of a class is also of class type, its value may be described as a nesting of such a set. Value of an object with recursive reference (include instance variables which refer itself directly or indirectly) cannot be expressed in this manner. These values may be assigned to an instance of the class.
4.3 Operators and Expressions
In order to carry out meaningful computation, we need an assortment of useful operators.
Operators can be either defined (programmed) by a user, defined by operating system in advance, or primitive (arithmetic) ones which cannot be decomposed further. Instance methods can be also invoked as operators. Since operators take strictly typed values as input, some operator overloading on input and output value types might be desirable.
Every operator is assumed to have implicit (default) input and output in addition to normal ones. These input/output can be used for synchronization of operations, and transfers null tokens which has no concrete value. If an arc is explicitly connected to this output, a null token is issued when its operation is completed. If an arc is explicitly connected to this input, the operator requires a null token to trigger itself. The input is always ready if no arc is connected to it. By connecting output of an operator to input of another operator by an arc, two operators will be forced to fire sequentially.
With respect to the primitive value types given above, full set of arithmetic operators
need be provided. The most of arithmetic operators are binary, with 2 input and 1
output. Integer division operator may have 2 output, one for quotient, and another for
remainder. For character string (text), typical string operators should be provided, such
T F
T F
as concatenation and sub string. Comparison operators are also needed for numerical value and character string. Some value type conversion operators are also required for each possible value conversion between primitive value types. As for aggregated value type, access operator may be required to extract primitive value from aggregated value.
Control structures are responsible to construct aggregated values, however, scatter/gather operators equivalent to parallel to serial/serial to parallel conversion may be explicitly defined. For an object type, every instance variable is provided with an operator to access its value, that is, an instance name itself is regarded as an access operator.
Interface to Operating System (Application Programming Interface, API) can be ac- cessed as predefined primitive operators. Value types and classes required for this interface should be also predefined. These definitions may be provided as parts of an Application Development Framework class library.
A method of an object is also an operator. In this case, the graphical syntax of oper- ators should identify the instance to which the method belongs; to designate a particular instance, to imply the current instance, and to specify the super (base) method.
4.4 Grouping and Control Structures
Any sub network of operators and arcs can be made into a group denoted as a single operator. All of incoming and outgoing arcs will become input/output of the operator.
An operator extracted from sub network can be named and used as a user defined operator.
This grouping mechanism, viewed in reverse order from an operator to a decomposed sub network, can be a support for the stepwise refinement programming methodology.
As for conditional control structure, basic conditional operations include switching and selection as shown in the following figure 7.
(a) Selection operator (b) Switch operator
Figure 7: Basic Conditional Operators
These conditional structure is too primitive, therefore a higher level conditional struc- ture may be better introduced in figure 8.
Here, B is a network (group) to calculate the condition, T and F are also networks (groups) to obey the condition. This structure roughly corresponds to the following fig- ure 9. These groups will be defined separately. Here, selection operator is assumed to short cut operation, where a token need not be present on unselected input to fire.
The repetition structure can be constructed in the same way, however, here aggregation
operator plays an essential part of the structure. Scatter and gather operators are provided
to handle aggregated value, the former decomposes an aggregated value into a stream of
constituent values, while the latter compose an aggregated value from a stream of basic
B T F
Figure 8: Conditional Construct
values. In this figure 10, shadow denotes aggregated value.
A repetition construct may be depicted by the following figure 11. Here, shadowed connector accepts aggregated values. At least one of input connector need be of aggregated value type.
This constructs is roughly equivalent to the next network in figure 12.
Here, S is a network which accepts non aggregated value, and repetition is implied by the scatter operator.
More generic repetition construct may be defined as follows in figure 13, where B is a network to calculate repetition condition, and S is the body of repetition, N calculate repetition step value. Output may be a gather operator. This construct is roughly equiv- alent to the next network in figure 14. In order to give truly generic iterative process, in addition to this basic construct, there might be necessary to define mechanism to pass values from one iteration to the next and to calculate values at loop termination.
So far, composite constructs to build a program are described. Any practical program should be constructed from these composite operators, however, at this time, there will be no proof for this to hold. It will be certified in the process of designing the concrete syntax and implementing the language processor by using the language itself.
5 Issues on Realization of the Data Flow Programming Lan- guage
5.1 Concrete Graphical Syntax and Editing
The concrete graphical representation of the language based on Data Flow Programming Scheme can be, in principle, arbitrarily designed, as far as it can be intuitively understood.
Therefore we can employ a format not much dissimilar to above examples. What we must determine are:
• Icon to represent each operators
• How arcs are connected to operators?
• Arcs and operators placement algorithm
• Concrete (graphical) representation of a class and class hierarchy
• Point and click editing interface
T F
T F
T F
B
Figure 9: Equivalent Conditional Construct
These issues are not concerned with the principles of the language, but with the ease of use of the language. Theoretical considerations cannot determine these matters, but long time of programming experience only can do.
It will take some time to produce a feasible design of the language, until then we will try to make a good effort to accomplish the goal of producing an easy to use language and programming environment.
5.2 Implementation Problems
As a matter of course, a language is hardly usable unless an interpreter and/or a com- piler are prepared for the language. Here, we must also make considerations on how to implement a compiler for the language based on Data Flow Language Scheme. As we stated above, the language has graphical representation, the internal structure of a pro- gram edited is already present in the language editor/processor. Therefore a compiler for the language need not to process lexical analysis and syntax parsing like as conventional compilers do. It only need to translate from internal structure of a program into an object program. We will give some basic guidelines for implementing the language processor and programming environment including an editor in the following.
• The compiler (language processor), editor, debugger (interpreter) are made as a con-
solidated programming environment. This environment should hopefully include the
interface to interactively build user interface (a la Interface Builder for NeXTstep).
S
(a) Gather operator (b) Scatter operator
Figure 10: Aggregation Operators
Figure 11: Repetition Construct
• The programming environment should be written in the language itself. This enables the programming environment to establish itself by bootstrapping. Presumably, this requires a generic, platform independent Application Framework to be written in the language. And this may also conclude the feasibility of the language in systems programming.
• To ease the burden imposed on the language processor, a higher language should be employed for the object program description. Object programs should be, for example, in C/C++, or Java. This also enables some code improvement by editing object programs. In case of Java, a platform independent class library is available.
The implementation must proceed with the concrete design of the language.
5.3 Compiling Algorithms
Here we will give some more issues related with the translation. The translation algorithm must intermediate the difference between Von Neumann architecture (or algorithmic lan- guage principle) and Data Flow Language Scheme. This seems rather formidable task.
The following is some keys to solve this problem.
• Arcs in a data flow program will be translated into local variables of corresponding data type in an algorithmic language.
• It seems the easiest translation is to generate interpretive code in the algorithmic
language.
S
B S N
Figure 12: Equivalent Repetition Construct
Figure 13: Generic Repetition Construct
• Operators will be translated into some test code for input ready and operation and test code for output busy.
• These operator code will be continually invoked in an outermost loop.
• Specifically, the language design proposed here does not acknowledge any explicit cyclic arcs in a group/module. In this case, an operator and its connected arcs are turned into a simple assignment statement, and these statements are ordered by the triggering dpendencies. The translation algorithm is far simpler.
These strategies will work, at least, in principle. It is suspected that the run time
efficiency, however, seems not much excellent. We should pursue to develop translation
algorithm for better efficiency, and that is an important research theme for the following
decade. This concludes our essay on future, or alternative, programming language.
T F
S N
B
