JP2021144369A - Data processing apparatus and data processing method - Google Patents

Abstract

To provide an environment which allows programming to be carried out by using only an input device with minimum functions.SOLUTION: According to the present invention, a graph format of a data flow graph is employed as an expression format for a program, and each command and option is surrounded with closed regions, thereby exchanging data between adjacent closed regions. Input and edition of a graph format is carried out only with designation of positions on a screen and designation of several kinds such as a single click and a double click.SELECTED DRAWING: Figure 7

Description

The present invention relates to input and editing of a programming language, a method of executing a program, and a method of controlling a device by a program.

Regarding the visual representation of the algorithm, the flowchart format defined by the JIS standard and various other notations have been devised. One of them is the data flow graph format, and some proposals have been made for the architecture of the data flow machine that directly executes the graph. In addition, for various data processing devices based on the graphical user interface and device control devices, we have also proposed and developed an event-driven architecture in the form of describing procedures that respond to events such as operator interventions and device state transitions. Some of these proposals are a combination of event-driven and object-oriented programming. An example is MicroSoft's C ++ language library called MFC.

Patent Document 1 shows that graphical programming of a PLC circuit is performed by a ladder diagram.

JP-A-2016-224559

"Data-driven parallel computer" ISBN4-274-07763-2

An object of the present invention is to provide a program creation execution environment that does not require much keyboard input, and to provide a device control device based on the execution environment.

In order to achieve the above purpose, a schematic expression format (programming "language") will be introduced as a program description format. A typical example of such a schematic representation format is a flowchart diagram, but the representation rules of the flowchart diagram are not as strict as necessary for a computer or interpretation execution, and a considerable degree of freedom and ambiguity are allowed in the description. Therefore, it is not suitable as it is as a direct interpretation execution instruction to the computer. In order to interpret and execute the flowchart diagram, it is necessary to impose considerable description restrictions. Also, looking at FIG. 5 as an example of a flow chart, it is not easy to input and edit without a physical keyboard because there is still a considerable amount of textual representation in the description of the process. Therefore, in order to adopt the expression diagram, strictness of description, less character input, and high readability of logic are required.

In the present invention, in order to realize programming on a digital device without a keyboard, such as a tablet or a smartphone, a visual expression using symbols and arrows is used instead of a text-based programming language as in a normal programming language. use.
Most programming languages today are written in textual text and require a full keyboard device for input creation and modification editing. For this reason, when trying to equip an embedded device with a function that allows the operation algorithm to be changed, it is necessary to mount a full keyboard or prepare an externally attachable terminal and connect an external keyboard.

For example, regarding the function of the operation start timer of the air conditioner, the standard method of specifying "start operation t hours after the current time" is provided as standard, and the API (Application Programming Interface) related to this function is open to the user. , Basic operations, basic operations such as "driving the device" and "reading the value of the built-in clock" are open to the public, and can be driven by the programming language processing mechanism installed in the air conditioner body. And.

With such a user-programmable air conditioner, the user changes the logic of the timer to perform programming to change the specification method so that it "starts at the specified time" instead of "starts after the specified time from the current time". Consider the case. Then, in the case of a text-based programming language, a large amount of character input is required for input and editing, and it is very difficult to work without a physical keyboard. Instead, the solution of equipping the air conditioner itself with a full keyboard also increases the cost of the entire device. It is also possible to attach a keyboard externally by equipping it with a USB terminal, but if the keyboard is used as an accessory for air conditioners, the cost problem will not be solved. In this example, the case of a relatively expensive device such as an air conditioner is considered, but this problem becomes remarkable when considering the application to an alarm clock or the like.

In order to solve such a problem, in the present invention, (1) a data flow graph is adopted as a program representation diagram. (2) As the arrangement of the graph, the cells of the execution unit called tiles are arranged adjacently on the "board surface". (3) The contents of the tile can be input only by pressing a button at a predetermined position on the screen, tapping, double tapping, selecting an item from the pop-up menu, and inputting a few to a dozen characters from the virtual keyboard. do.

By the above means, programming in a schematic representation format having the same expressive ability as a normal programming language can be performed only with a touch panel without a costly physical keyboard. In addition, it is possible to realize a general-purpose program development environment that can be programmed on devices such as smartphones, smart speakers, and tablet devices.

Outline of expected equipment configuration The figure which shows the screen display of the 1st Embodiment of this invention Illustrative tile notation of the first embodiment Graph chart of character string printing program. Operation flowchart of the execution system of the first embodiment Mainline chart of the program to calculate factorial Program chart of tile "n!" To calculate factorial Transformation of the mainline chart to calculate factorial Flow chart of output passing of the first embodiment Flowchart of "passing to the left side" of the first embodiment New tile creation dialog Enlarged edit dialog Instruction setting dialog Command / name list pull-down menu A description of the zone that distinguishes the tap positions in the tile Description of the priority attached to the specified input / output Event handler flowchart when a tile is single tapped Flowchart of event handler when tile is double tapped Flowchart of direction editing process Inside the program execution engine of the first embodiment Description of the main predefined instructions Example of state transition of input / output instruction Inside the program execution engine of the second embodiment The figure which shows the screen display of the 2nd Embodiment Illustrative tile notation of the second embodiment Graph chart of the character string printing program of the second embodiment Operation flowchart and initial data chart of the execution system of the second embodiment Program chart of evaluation execution procedure method of context structure Detailed view of context structure and waiter Flowchart of grid object execution evaluation procedure Flowchart of method search process for tokens Detailed structural view of the distribution data token of the second embodiment Class hierarchy diagram of data tokens in the second embodiment Details and specific examples of the event registration table held by the API mediation department of the second embodiment Data token example and dialog example of the application of the second embodiment ADD button press event handler OnADD program chart Program chart of event handler generation method Init Program chart of event handler creation method AddOn Display instruction rewriting method RepLBL program chart Program chart of operation instruction rewriting method RepOP Program chart of T-class JCT method

A typical embodiment of the present invention is shown below. This example is an application of a general-purpose programming environment to device control. The difference between the device control execution environment and the general-purpose environment is whether or not it has an API for device control, and in this example, the API corresponds to whether or not it is defined as a "built-in tile" described later, and therefore. This example does not limit the execution environment of the present invention to application to device control.

FIG. 1 is a schematic diagram common to this embodiment, and is a diagram of a configuration in which the data processing device of the embodiment controls an embedded device. As an example, when the embedded device is an air conditioner, 101 is the entire air conditioner device, 102 is the air conditioner device body, 103 is the start / stop switch, 104 is the built-in clock, and 105 is the interface for controlling 103 and 104 by 106. , 106 can be regarded as a program execution engine that controls these devices, and 107 can be regarded as a touch panel that inputs and outputs with the user. For a general-purpose programming environment, 102,103,104,105 may be removed from this configuration diagram.

(First Embodiment)

FIG. 20 is an example showing the inside of the program execution engine 106 of FIG. 1 in the first embodiment. 2001 in FIG. 20 corresponds to 106 in FIG. The program execution engine 2001 has a UI operation processing unit 2002, which responds to operations, taps, double taps, etc. on the touch panel 107 to define the actions to be executed for the tile holding unit 2005 and the execution interpretation unit 2003. Give instructions.

2003 is the program interpretation execution unit, and the operation should be executed from the predefined tile holding unit 2005 that starts the operation when the program execution is instructed by the UI operation processing unit 2002 and holds the predefined tiles corresponding to the program. Is taken out, various information is repeatedly written / read to the execution environment holding unit 2004 and the work area 2006 to execute the execution, and when the execution is completed, the fact is reported to the UI operation processing unit 2002. In addition, the interpretation execution unit 2003 calls the processing for the interface of 106 in FIG. 1, reads the status of the device, and operates.

2004 is an execution environment holding unit, which holds various information at the time of execution. This information includes the meeting place of the tile waiting to be executed, the information of the data reaching the tile waiting to be executed, and the like.

2005 is the storage section for predefined tiles. This is the part that stores the "predefined tiles" that are created and edited by the user. A "defined tile" is a name given to a data flow graph constructed by arranging a plurality of tiles. This 2005 part provides information on tiles at a specified position on a defined tile with a particular name, as requested by the 2003 Interpretation Execution Department. In addition, a newly defined tile is created, deleted, and the contents are changed according to the instruction from the UI processing operation unit 2002.

The work area 2006 is a place for storing various data distributed in the data flow graph, and stores the substance of a composite object such as a character string or a structure.

FIG. 2 is a display example on the user screen in the first embodiment. On this screen, if the execution has already started, the character string "HELLO WORLD" is displayed in the display area 201, and the state of being programmed to end the execution is displayed. In this system example, assuming a user who gives an execution instruction to the system immediately after starting the system, a state in which such a program is already set is given as an initial state. A detailed description of FIG. 2 will be described later. Only the basic components will be described here.

In 211, 212, and 213, diagrams are drawn that indicate execution options called execution instructions and operands, the direction in which input data enters, and the direction in which output data is discharged, respectively. This rectangle is hereafter referred to as the "tile". Details regarding tiles are described in FIG. The tiles have a rectangular shape in this embodiment, but any closed area that can be adjacent to each other may be used, and the tiles do not have to have the same shape.

208 is an area where tiles are arranged vertically and horizontally adjacent to each other, and is an area for displaying and editing the arrangement status of "defined tiles". This area is hereinafter referred to as the "board surface". A "name" is given to the board for identification. The board of 208 is named "Main Line", and the name is displayed in the display area and pull-down menu 207.

A detailed explanation of FIG. 2 will be given. First, the "program" expressed on this Main Line board will be briefly explained. 211 executes an instruction called the instruction identifier CONST. This command receives input data from above the tile, ignores the contents of any input data, and uses the optional string "HELLO WORLD" as output data for this tile. Pass to the adjacent tile below. 212 executes an instruction called the identifier PRT. This command takes data from the tiles adjacent to the top as input and prints its contents in the display area of 201. Furthermore, the input data is passed as it is to the adjacent tile below. 213 executes an instruction called identifier END. This instruction takes data from the tiles adjacent above it as input, discards it, and outputs nothing. In this program, the execution of 213 discards the data, and the execution of the system ends when there is no data circulating in the entire program system. The arrows in this program indicate the data distribution route, not the control flow, and the diagram is a data flow graph.

Reference numeral 202 denotes a push button labeled "RUN", and when pressed, execution of the set program is started. When this button is pressed, a dummy data token NIL that triggers execution is dropped from above the tile 211 at the center of the upper side of the board shown in 208, and the tiles that have been able to be executed since the necessary data arrived. Execution continues. The token dropped first triggers the execution of the entire system, and in this first embodiment, it may be 0 or 1 instead of NIL.

Reference numeral 203 is a push button labeled "NEW TILE", which can be pressed to create a new defined tile with a new name identifier. Details will be described later. The name identifier attached to the defined tile can be used as an instruction identifier in the tile, and by creating a new defined tile, the algorithm can be used as a subroutine on the board. For example, the defined tile "n!" Edited to calculate the factorial of an integer as shown in Fig. 7 can be used in the tiles on the board as shown in Fig. 6 in the same way as CONST and END.

207 is a display area and pull-down menu, and MainLine and the name identifiers of all the defined tiles created up to that point are listed as selection candidates. When the user selects an identifier from this menu, the display of 208 switches to the contents of the board of the selected identifier and can be edited. The 207 serves both as a display switch and a display of the board name currently displayed on the 208.

In this embodiment, the board surface has an odd number of tiles in both vertical and horizontal directions such as 3 × 3, 5 × 5, and 7 × 7. This is an odd number because the positions of the top, bottom, right, and left, which are the input / output directions of the named board, are the center tiles of each side, but if the input / output positions of each side can be specified by another method, It does not have to be an odd number. Further, as long as the tiles can maintain the adjacency relationship, the number of tiles in the vertical and horizontal directions does not have to be the same, and the shape of the tiles does not have to be rectangular. For example, in the case of hexagonal tiles, if the number of tiles adjacent to one tile is rectangular, it is possible to increase the number from four to six.

The display area 209 labeled "IN:" is an area for displaying the conditions under which the displayed board can be executed. Each tile receives one or more data inputs, but you can set how many data arrives from which direction to execute. 209 is the display area. In this example, T: Top, that is, it is possible to start the execution of the board called MainLine when the data arrives from above. On the other hand, each tile has 0 or more outputs, and which direction is the output is displayed in the 210 area labeled "OUT:". In this example, MainLine does not output to the outside, so the 210 column is blank.

Figure 3 shows the display details of each tile. 301 in Figure 3 (a) is a reprint of the CONST instruction tile illustrated in 211. Reference numeral 302 denotes a straight line that is not an arrow, indicating that an external input comes in from this direction, that is, from above. 303 is an identifier for the input data. This is given assuming an instruction tile that has a plurality of inputs and whose result changes unless the inputs are distinguished, for example, an instruction such as subtraction or division. In this embodiment, numbers are used for the identifiers, but alphabets or the like may be used as long as the identifiers can be ordered.

304 is an identifier display of the instruction. Here, the CONST instruction that outputs a constant is written. In addition, it is possible not only to set the instruction prepared in advance by the program execution system, but also to set the identifier name of the defined tile created by the programmer. 305 is an option display for the execution instruction of 304. Since CONST does not determine what kind of constant is output only by the instruction, specify the constant as an option. Some instructions do not require options.

The outward arrow at 306 indicates that there is output in this direction, for the tiles adjacent below in this example. Like the input, the output is given an identifier and is displayed along the arrow like 307.

308 in Fig. 3 (b) is an instruction tile with multiple inputs and outputs, a SWITCH instruction tile. SWITCH is an instruction that has two inputs and two outputs. If input 1 is NIL, the data that came in as input 0 is output to output 1, otherwise input 0 is output to output 0. .. In this SWITCH instruction, the data is ejected to either output 0 or output 1, and no data is ejected from both. The SWITCH instruction corresponds to a conditional branch that switches the output by regarding the data NIL as a false logical value. In 308, input 0 enters from the tile adjacent to the top, input 1 enters from the left, and is passed as output 0 to the bottom and output 1 to the tile adjacent to the right. 310 indicates that the input from the left is input 1, and 311 indicates that the output to the right is output 1.

In 308, input 0, input 1, output 0, and output 1 are set as top, left, bottom, and right, respectively, but in this embodiment, the input direction and output direction of each command tile are free. Can be selected and set to. Since the direction can be set freely, it is necessary to give an identifier to the input / output to avoid confusion.

FIG. 4 shows an extracted and deformed part of the MainLine board surface displayed in FIG. The position of the END instruction tile is different from that in Fig. 2, but it is the same as the representation of the algorithm. Here, 407 indicates that the display of the current board is MainLine, and 408 is a simplified illustration of 209 in FIG. 2, and the condition "T" that the MainLine board can start execution is It is displayed. In the case of T alone, if data enters from above, the board can be executed. In this example, when the RUN button of 202 in FIG. 2 is pressed, the data token NIL enters from 401 on this board.

The input data NIL is received by tile 402 as input 0. Tile 402 can be executed by receiving this data, and the instruction CONST is immediately executed with the option "HELLO WORLD". As a result of execution, the data token of the character string "HELLO WORLD" is passed to the adjacent tile 403 below as output 0 of 402. Tile 403 is set to receive data from above as input 0, and as a result, the PRT of instruction 404 of tile 403 can be executed, and it is executed after 402. As a result of executing 404, the input character string "HELLO WORLD" token is displayed in the display area 201, and then passed as it is as output 0 to the tile 405 on the right side. Tile 405 has END set as instruction 406. Tile 405 receives the token of the character string "HELLO WORLD" as input 0 from the tile 403 on the left. Tile 405 is executed after 403 because END can be executed when data arrives at input 0. As a result of executing this END, the token of the input character string data "HELLO WORLD" is abandoned. As a result, none of the tiles in this system can be executed, so the execution mechanism ends the process.

The formula of the execution start condition displayed in 408 of FIG. 4 and 209 of FIG. 2 has the following format in the first embodiment. The execution start condition is expressed by all of a plurality of inputs arriving, one of a plurality of inputs arriving, or a combination thereof. In the above case, the direction symbols of the inputs are connected by an operator *, and the latter In case, connect with operator +. As for the priority, * is stronger than +. Also, parentheses () can generally be used in the same way as mathematical formulas.

As the input direction symbol, each character of T, L, R, and B can be used, and represents top, left, right, and bottom, respectively. In mathematical formulas, the order of appearance of this symbol from the left specifies the input identifier. For example, the input conditional expression "T * L" indicates that it can be executed when data arrives from both the top and the left, and T is input 0, L corresponding to the order of appearance of the direction characters. Also indicates that is corresponding to input 1. If any of the direction symbols is specified alone, the specified board becomes feasible as soon as the data from that direction arrives. The formula "(T * R) + B" as a complicated example means that input 0 comes in from the top, input 1 comes from the right, and input 2 comes in from the bottom in the order of appearance of symbols, and when input 2 arrives. So it can be executed regardless of other inputs. Further, even if the data does not arrive at the input 2, the expression expresses the condition that can be executed when the data arrives at the input 0 and the input 1.

Here are some examples of such conditional expressions. First, "L" is a conditional expression that can be executed when input 0 is input from the left and input 0 arrives. Also, "R * L" input 0 is input from the right, input 1 is input from the left, and it is a conditional expression that is not executed until both input 0 and input 1 arrive. Furthermore, "T + L" is a conditional expression that can be executed if input 0 is input from the top and input 1 is input from the left, and either of them arrives. And for "(T * R) + B", input 0 is input from the top, input 1 is input from the right, input 2 is input from the bottom, and input 2 arrives. It is a conditional expression that starts execution when either input 0 or input 1 is satisfied.

The interpretation of these formulas can be interpreted by general mathematical lexical analysis algorithms. Further, in order to simplify the interpretation process of this conditional expression, the notation of the expression may be the postfix notation (reverse Polish notation). In the case of such postfix notation, the conditional expression "(T * R) + B" becomes "TR * B +".

Such a graphic representation of the defined tile uses the identifier of the defined tile as a key, the input condition expression, the output direction character string and the board size information displayed in 210, and the coordinate information of each non-blank tile and each of them. It is stored in the defined tile holder of 2005 as an intermediate format in a table whose values are the structure including the input entry direction, instruction identifier, option character string and each output direction.

FIG. 5 is a flowchart showing the operation of the interpretation execution unit of FIG. 20 2003 in the 106 execution engines of this programming language. When the interpreter is started, it completely resets the various storage areas required for execution, as in 501 first. These storage areas include an area for waiting when there are multiple executable tiles, an area for waiting for tiles that are not executable but some data has arrived, arrays, lists, and structures. Contains heap areas for complex data structures such as. These areas correspond to the execution environment holding unit 2004 and the work area 2006 in FIG.

Next, the interpretation system calls the chart named "MainLine" from 2005 in Fig. 20, which is the holding part of the predefined tiles programmed as shown in 502, and triggers the activation from above for this board chart. Insert the data token NIL that gives.

In the next 504, the interpretation system searches for the tiles that have become executable among the tiles on the board, and executes one of them. For the search, refer to the execution environment holding unit 2004 in FIG. If there are multiple tiles that can be executed, they may be randomly selected and executed, or the one with the longest elapsed time since it became executable in chronological order should be selected and executed. May be good.

Execution of the tiles in step 504 results in zero or more outputs. In step 505, processing is performed to distribute these outputs as inputs of adjacent tiles. If there are 0 outputs, nothing is done in step 505. When there are 1 to 3 outputs, the process of passing each output as an input of adjacent tiles in each direction is performed for the number of outputs.

Data tokens may be passed to some adjacent tiles as a result of the processing in step 505, resulting in some viable tiles. Those tiles are also included in the candidates and returned to step 503 to determine if there are viable tiles, and if so, one is executed in step 504. This repetition is repeated until there are no more feasible tiles, and the interpretation system is stopped when there are no feasible tiles. Depending on the contents of the tile definition of the program to be executed, the data may continue to rotate indefinitely, but on the other hand, the number of executed tiles is counted during interruption or repetition. However, it is also possible to easily stop after executing a predetermined amount, or add a mechanism to confirm the continuation to the user.

Figures 6 and 7 illustrate more complex program charts. In this example, a program that calculates the factorial of the natural numerical value input by the user, displays it in the display area 201, and stops it is realized. FIG. 6 is a main line chart, and 601 indicates that the name of this board chart is "Main Line", and 602 indicates that the executable condition of this chart is the arrival of data from above.

When NIL is dropped from above by the initialization process of the interpretation system, tile 603 becomes executable first. The instruction for this tile is INPUT. The INPUT command requests the user to input one input by means such as a dialog and a virtual keyboard, and outputs the data to output 0. At this time, the reference of the data input to input 0 is abandoned. The input data is passed to tile 604 from above and received as input 0.

"N!" Is specified in the instruction of tile 604. "N!" Is the name identifier given to the defined tile displayed in Figure 7. On tile 604, it is instructed to input an integer of input 0 to the definition board surface of FIG. 7 and pass the result as output 0 to the adjacent tile below as input. The result is passed to the tile of the adjacent PRT below, and subsequent executions proceed in the same way as in the example in Figure 2.

Figure 7 shows the mounting board chart of the predefined tile "n!" That calculates the factorial. In 701, it is displayed that the name given to this chart is "n!". In 703, the execution start condition of this chart is the arrival of data from the top, and it is displayed that the data received as input 0 is entered from the top. In 702, as a result of executing this chart, one output is output from the bottom, and it is displayed that it corresponds to output 0. These names, input conditions, output settings, etc. can be set in the dialog 1101 of FIG. 11 displayed when the button 203 for creating a new tile definition is pressed.

In the board chart of FIG. 7, an algorithm for recursively calculating the factorial is defined in the data flowchart. "Factial of natural number n" can be calculated as "n! = 1 if n = 1" and "n! = N × (n-1)! If n> 1". Is displayed.

A natural number with input 0 coming in from above under the condition of 703 is accepted as input 0 on tile 704.

The 704 has no indication of instructions. This is a simple display of the command COPY3. A tile with no instruction indication on the tile, one input and three outputs can be identified as a COPY3 instruction tile. However, the display of the instruction identifier COPY3 is simply omitted. COPY3 is an instruction that duplicates two more data of input 0 and passes three outputs one by one to output 0, output 1, and output 2. In the 704, the natural number of input 0 is duplicated and supplied to the tile 706 adjacent to the left, the tile 705 adjacent to the right, and the tile 708 adjacent below.

Tile 705 also has no instruction name. However, unlike tile 704, it has the same input but only one output. This is a simple display of the command PASS. The instruction display is omitted on the tile, and the tile with only one input and one output is determined to be the tile of the PASS instruction. The PASS instruction is an instruction to pass the data received as input 0 to the adjacent tile as output 0 without any processing. The 705 tile passes the data received from the 704 to the 707.

Tile 706 is a CONST tile, and the natural number 1 is specified as an option. This tile receives data input from 704 and passes the natural number 1 to the adjacent PASS instruction below it. As a result, the output 0 of the 706 is supplied to the 708 via the tile of the PASS instruction.

Tile 708 is a tile of instructions for performing a comparison operation called GT. The GT instruction takes two inputs and can be executed when both data arrive. The execution operation compares input 0 and input 1, and outputs data T representing the logical value true if input 0> input 1, and outputs data NIL representing the logical value false otherwise to output 0. Input 0 of 708 is the number passed to this board, input 1 is the natural number 1, and the combination of these tiles 704, 706, 708 compares whether the natural number supplied from above to this board is greater than 1. It is carried out.

Tile 707 is a tile of an instruction that performs a conditional branch operation called a SWITCH instruction. As mentioned above, the SWITCH instruction takes two inputs and can be executed when both data arrive. In the execution operation, when the input 1 is data other than NIL, the data of the input 0 is sent to the output 0, and when the input 1 is NIL, the data of the input 0 is sent to the output 1.

In the SWITCH instruction of 707, the natural number supplied to this board as input 0 receives the result of the comparison operation of tile 708 as input 1. If the comparison result is true, i.e. greater than 1, input 0 is fed to tile 709, and if less than 1, input 0 is fed to tile 715 as output 1 through the PASS instruction tile to the right. By this SWICH, the data flow graph branches into a graph that calculates n × (n-1)! Starting from tile 709 and a graph that outputs 1 as a result starting from tile 715.

Tile 709 does not display an instruction string, has one input and two outputs. Such tiles are identified as COPY2 instruction tiles. The COPY2 instruction can be executed when data arrives at input 0. The execution operation is to duplicate the data of input 0 and send it to output 0 and output 1 one by one. In the simple display of the COPY2 tile, only the input and output arrow lines are displayed, and the display of the instruction character string is omitted.

Tile 709 is executed when the input data is greater than 1 as a result of the comparative branch graph. When executed, the data at input 0 is duplicated, passing the data to tile 710 and tile 712.

Tile 710 is an "n-1" instruction tile that subtracts 1 from the contents of the input data. This instruction becomes executable when data reaches input 0. In the execution operation, the value obtained by subtracting 1 from the data of input 0 is sent as output 0. The tile 710 passes the value obtained by subtracting 1 from the data supplied from the tile 709 as the output 0 to the tile 711.

Tile 711 is a tile that instructs the execution of the defined named board "n!". "N!" Is defined on this board, and this call is recursive. Tile 711 calculates "n!" Based on its own definition for the number subtracted by 1 by tile 710, and passes the result as output 0 to the tile 712 adjacent to the right.

Such a recursive board chart call has a structure such as a method in which the chart itself is duplicated at the timing of the call and executed in a separate graph, or a stack in which the call history is stored hierarchically without duplicating the graph. It can be realized by the method realized by using.

Tile 712 is a tile that executes the instruction "A * B" to calculate the arithmetic product of two data. "A * B" becomes executable when data arrives at both input 0 and input 1. The execution operation is to execute the multiplication of input 0 and input 1 and send the result to output 0. Tile 712 calculates the product of the number n passed from tile 709 and the factorial calculation result of n-1 passed from tile 711, and passes the result as output 0 to the adjacent tile 714 below.

Tile 714 omits the display of the command string and has two inputs and one output. Such tiles can be identified as a simple display of MRG2 instruction tiles. The MRG2 instruction takes two inputs and becomes executable when data arrives at either input. The execution operation is to flow the input data of input 0 or input 1 to output 0 without any processing, and has the purpose of merging the paths of two data flows into one.

Tile 714 receives the operation result of tile 712 as input 1, that is, the result of n × (n-1) !, and the constant 1 from tile 715 as input 0, and if data arrives at either of them, that data is input. It is supplied as output 0 to the tile 713 adjacent to the left. Tile 714 is the confluence of data from two data flow graphs, a graph starting at tile 709 and a graph consisting of tile 715 and multiple PASS instruction tiles, and the data for these two graphs is tile 707. Since it is separated by SWITCH of, the structure of the board chart is such that data is supplied to only one of the graphs.

In this definition of n !, output 0 is supposed to exit from the bottom as shown by 702. However, in this embodiment, input / output from each direction is limited to be performed only from the central tile among the tiles adjacent to each side. That is, on the 5 × 5 definition board, input / output from above can be performed only on the tile in the center of the upper side, and in FIG. 7, only the tile 704. Similarly, the input / output in the left direction is the tile in the center of the left side. The tiles in the right direction are the tiles in the center of the right side, the tiles in the lower direction are the tiles in the center of the lower side, and in Fig. 7, the tiles are limited to tile 713. In this embodiment, the number of tiles on each side is limited to an odd number, so that there is always a central tile on each side. The input / output positions are not limited to the center of each side, and a method may be used in which the tiles are marked with distinguishable marks such as colors.

Due to the above rule setting, output 0 of tile 714 does not directly touch the bottom edge, but touches the bottom edge via tile 713. As a result, the graph in this part is bent.

In this embodiment, the logic of factorial calculation is expressed by the configuration of such a data flow graph, and can be executed by the interpretation system that realizes the processing flow of FIG.

FIG. 8 is a modification of FIG. 6, which is a main line graph for calling “n!” As defined in FIG. 7. Although the graph is bent compared to FIG. 6, the logic of the expressed graph is exactly the same as that of the graph of FIG.

The tile 805 in the center of the chart is a tile that executes the named board name definition tile "n!". This tile 805 receives 801 which is the output 0 of the tile adjacent to the right as the input 0 from the right. Also, the output 0 is sent to the left and is received by the input 0 804 from the right of the tile adjacent to the left. The interpretation system of this embodiment is equipped with a process related to data transfer between adjacent tiles.

FIG. 9 is a flowchart of the processing of the interpretation execution unit 2003 regarding this delivery. This "output passing" process is executed when an output is generated by executing the tile, and corresponds to the process of step 505 in FIG. This procedure is performed once for each output if there are multiple outputs.

This process is branched into four procedures by the conditional inspection below from step 901 depending on the direction of the output generated. If the output is to the left, the procedure is "pass to the left", if the output is to the right, "pass to the right", and if the output is downward, "pass to the bottom". At the time of output, "pass to the upper neighbor" is executed.

FIG. 10 is a flowchart of the process of “passing to the left” called in step 902 of FIG. Extract the passed data referenced in this procedure in step 1001. In step 1002, the identifier of the input to the right of the tile to the left is retrieved. In the chart of FIG. 8, the data passed in the output 801 to the right corresponds to D, and the input identifier 0 of the tile 805 on the left corresponds to P. In step 1003, the data D to be passed is substituted as the input P of the tile on the left. As a result, the data arrives at the tile on the left, so it is step 1004 to check the feasibility of the tile on the left with the executable conditional expression of the instruction on the tile on the left. As a result, when it is determined that the tile is feasible, the tile to the left is classified as feasible and is a candidate for execution in the execution step 504 of the next tile.

The process of passing data in other directions can be realized by replacing "left and right" in the processing description in FIG. 10 with the relations of "right and left", "top and bottom", and "bottom and top". ..

Next, in the first embodiment, it is shown that the creation and editing of these data flow graphs can be performed by a position specifying means such as a touch panel, two instruction means such as a tap and a double tap, and a virtual keyboard.

FIG. 11 is an input screen when creating a new named board tile. When the button 203 in FIG. 2 is pressed, a new named board surface is created. Dialog 1101 is displayed as a modal dialog for inputting various information required at this time. At this stage, set the board name, board size, executable judgment formula, number of outputs and direction, and after setting with 1101, tap or double tap the screen on the board display 208. Do it with.

1102 is a text input item, and the name of the board is input here with a virtual keyboard or the like. 1103 is a pull-down menu that specifies the size of this named board, and odd numbers such as 3, 5, and 7 can be selected. In this embodiment, since the board surface is defined to have the same vertical and horizontal sizes, only one numerical value is input, but in other cases, an appropriate number of appropriate values are prompted to be input. Reference numeral 1104 is an executable conditional expression of this named board, and the conditional expression of the above-mentioned format is input by a virtual keyboard or the like. For this item, there may be a UI mechanism such as an auxiliary dialog that assists in input. In this example, the execution start conditional expression has two inputs, input 0 comes from the top and input 1 comes from the left, and can be executed when both input 0 and input 1 data are available. It is set to become. 1105 is a text input item that sets the number and direction of outputs. In this example, it is set that there are two outputs, output 0 goes down, and output 1 goes out to the right. For this item as well, the amount of character input can be further reduced by introducing an input support dialog.

The OK button in the 1101 dialog closes the dialog by registering the settings as confirmed. When the Cancel button is pressed, the operation itself for creating a new named board is canceled.

When a new named board is created by pressing the OK button, a board with all tiles on the board initialized with blanks is created, the board name is displayed in 207, and the current board is displayed in 208. The contents and initial state are all tiles that are blank. The board is created and edited by tapping or double-tapping each of the 208 tiles.

FIG. 12 shows the display contents when each tile is double-tapped. 1201 is a modal dialog that is displayed in approximately the same size as the area displayed in 208 in FIG. 2 to facilitate tile editing operations. In 1202, the same contents as the double-tapped tile are enlarged and displayed in the full dialog. You can edit the contents of 1202 with a single tap. When the OK button of 1201 is pressed, the result of the above editing is reflected in the double-tapped tile and the dialog is closed. The Cancel button abandons the result of the edit and closes the dialog with the contents of the double-tapped tile unchanged.

FIG. 13 is a dialog that is displayed modally when each tile of 208 is double-tapped or when a single tap is made near the center of the enlarged 1202 area. Here you can edit the instructions and options displayed in the center of the tile. 1302 is a pull-down menu that lists the name identifiers of all named predefined tiles, including those provided by the system and those currently being edited, and the user chooses one of them. select. 1303 is a text input item for inputting options, the contents can be input with a virtual keyboard, and some constants NIL, 0, 1 etc. can be set by selecting from the pull-down menu.

When the OK button in the dialog 1301 is pressed, the edited contents are reflected in the corresponding tile and the 1301 is closed. The Cancel button abandons the edit and closes 1301.

Figure 14 is an example of a menu that pops up when you tap 1302.
The 1401 menu is displayed with all system-defined instructions and pre-created named board names available for selection. The created board also includes the name of the board currently being edited, which is displayed in 208. In this example, the currently set instruction is highlighted. Regarding the order of these displays, it is conceivable to arrange them in lexicographic order of names or in order of frequency of use. 1402 is an item called "--EMPTY-", and if you select this, the corresponding tile will be set to blank and reset.

FIG. 21 is an example of a system-defined instruction. These include instructions for manipulating symbols, numbers, and strings, as well as instructions for handling binary tree lists as complex data structures, such as FRIST, REST, CONS, EQ, and ATOM ?. .. The instruction EQ may include a comparison function when the inputs are numerical values.

In addition, among the system-defined instructions in Fig. 21, there are also instructions such as ON? To read the power status, POWER to instruct power on / off, NOW to get the current time, and STTMR to set the time to the timer. include. This corresponds to a control command for the air conditioner device 102 to be controlled. In addition to this example, commands such as reading or setting the temperature setting of the air conditioner may be added.

The operation when a single tap is made on each tile of the board display 208 of FIG. 2 or 1202 of the enlarged display of the tile is determined by the tapped place in the first embodiment and the second embodiment described later. The edit target is distinguished. FIG. 15 is a description of the area for tap locations. 1501 is a square area of the entire tile, the interior of which is divided into nine areas. Of these, the central area 1502 will be referred to as "Zone 1", and the area along the upper side will be referred to as "Zone 2", the area along the left side will be "Zone 3", the area along the right side will be "Zone 4", and the area along the lower side will be "Zone 5". I will call it. In this example, the four corner areas have no name, and even if this area is single-tapped, nothing is processed. In the example, zone 1 is set to be large, but the size of each zone may be equalized, and the size of these areas is set based on the operability of the user.

In the above, the description "single tap near the center of the 1202 area" corresponds to single tapping the zone 1 of the enlarged display area 1202.

In the first and second embodiments, the zone 1 single tap edits instructions and options. Also, if you single-tap Zone 2, you can set the input / output in the upward direction. Similarly, zone 3 edits input / output to the left, zone 4 edits to the right, and zone 5 edits input / output downward.

When each zone is single-tapped, a dedicated dialog may be displayed and one of input 0, input 1, input 2, input 3, output 0, output 1, and output 2 may be selected and set. In both embodiments, the means having better operability will be illustrated.

In the first embodiment and the second embodiment described later, as an operation when each zone is single-tapped, if the input / output is already set in the direction corresponding to the zone, the setting is deleted. If it is not set, the setting operation is performed according to the rule that unset input / output is set in the order of priority set as shown in FIG.

For example, FIG. 22 shows an example of a single tap operation for an instruction having two inputs and two outputs. It is assumed that the initial state is 2201 in which only the SWITCH instruction, which is a 2-input 2-output instruction, is set. Next, when you tap Zone 2 first, input 0 is set upward as in 2002. Next, when you tap zone 4, input 1 is set to the unset right direction like 2203. Next, when you tap zone 3, output 0 is set to the unset left direction like 2204. Furthermore, if you tap Zone 4 again here, the setting of input 1 in the right direction will be deleted and the setting in the right direction will be unset, as in 2205. Next, when you tap Zone 5, 2206 is not set downward, and among the valid directions that have not been selected yet, the highest priority in light of Fig. 16, input 1, that is, the setting destination by the previous tap operation The input position that has disappeared is set in preference to the output 1 that has not been assigned yet. It is such an operation. Of course, after this, if you tap Zone 4, the only remaining unassigned output 1 like 2207 will be set to the right.

FIG. 17 is a flowchart of processing of the UI operation processing unit 2002 regarding such a single tap operation. The process starts from step 1701 of determining the tapped area first, and switches the process depending on whether the tapped area is zone 1 or not. If zone 1 is tapped, the dialog 1301 is displayed modally in step 1702 and the command and option settings are edited. If any other area is tapped, the input / output settings for each direction are set by the "direction edit" procedure in step 1703.

FIG. 18 is a flowchart of the UI operation processing unit 2002 regarding the operation when the display area is double-tapped. The double tap performs the following operations regardless of the tapped area. As mentioned above, if you double-tap the tile display area, the enlargement dialog 1201 is displayed, but it is also possible that the enlarged tile display 1202 in it is also double-tapped. In that case, it is not necessary to display the enlarged dialog again, so it ends without doing anything. Step 1801 is a judgment step for that purpose, and if the tapped display area is 1202, it ends without doing anything. If the tapped area is one tile in the 208 display, in step 1802, display the enlarged edit dialog 1201 of the tapped tile, let the user perform the editing operation, and then press the OK button. When it is closed, the edited contents are reflected on the tile and the process ends.

FIG. 19 is a flowchart showing the process of “direction editing” in step 1703 of FIG. Here, processing is performed when an area other than zone 1 is single-tapped. First, it is confirmed that the area tapped in step 1901 is not the area of the four corners that are neither zones 2, 3, 4, or 5. If it is the area of the four corners, it ends without doing anything. If it is any of zones 2, 3, 4, 5, it is further determined in step 1902 whether the input / output is set in the direction corresponding to that zone. If the input / output has already been set, the input / output set in step 1903 is canceled. The released I / O is processed to be included in the reassignment candidates in step 1904. If there is no input / output setting in the tapped zone, the setting process is performed in step 1904. In step 1904, among the inputs / outputs that have not been set and the inputs / outputs that have been released, the input / output having the highest priority in light of the priority shown in FIG. 16 is set.

The user operations so far are only tap and double tap on the display, click and double click in the case of the pointing device, and input the character of the name of the named board and the option character string. Most of the character input is words and numbers, and the length is such that it can be easily input with a virtual keyboard.

By providing the above-mentioned graphical representation programming language and user interface, a display and pointing device that does not require a physical keyboard, or a programming environment using only a touch panel can be realized. In essence, it may be a means for designating a position on the screen and an input / output device capable of giving two distinct instructions, for example, a cross key of a game controller and A and B buttons.

(Second embodiment)

The second embodiment is a modification of the first embodiment described above, in which an event-driven and object-oriented paradigm is introduced into the interpretation execution system.

FIG. 23 is an example showing the inside of the program execution engine 106 of FIG. 1 in the second embodiment. 2302 in FIG. 23 corresponds to the connection to 107 in FIG. 1 and corresponds to the connection to the 207 control device interface 105. The program execution engine 2301 corresponding to 106 in the present embodiment uses the API intermediary unit 2305 as a window, and responds to operations such as tapping and double tapping on the touch panel 107, changes in the power supply state from the control device, and the like. The corresponding object is taken from the mediation unit 2305, and the execution interpretation unit 2303 executes the evaluation method.

2303 is the program interpretation execution unit, and the API mediation unit 2305 holds an object that has a callback corresponding to the operation event on the touch panel 107 and the power state of 103 in Fig. 1 and the event that occurred in the built-in clock of 104. Take out from the registration table of 3401 in Fig. 34, which will be described later, start the execution operation of the evaluation method, write / read various information to the execution environment holding unit 2304 and the work area 2306 repeatedly, and execute it when the execution is completed. This is displayed in 107 of the UI touch panel Figure 1 through the API mediation section of 2305. Further, the interpretation execution unit 2303 responds to an event from the interface of 106 in FIG. 1 and calls an operation process through the mediation unit of 2305. In this embodiment, 103 power supplies and 104 built-in clocks are exemplified as event generation sources from within the control device, but events such as changes in the detection temperature of the air conditioner and changes in the internal conditions specific to the target device also occur. Considered as a source.

2304 is an execution environment holding unit, and is a part that holds various information at the time of execution. This information includes temporary work data necessary for executing the data flow graph, such as the meeting place of the tile waiting to be executed and the information of the data reaching the tile waiting to be executed.

2305 is an API mediator and consists of two functions. One is a table and its management function that uses the identifier of the event to be processed as a reaction from the UI and control device as a key, the instruction message identifier, and the reference to the object to which the instruction message identifier is sent. The other is a function of mediating the operation of the external device and the UI touch panel 107 of FIG. 1 from the interpretation execution unit 2303.

The work area 2306 of the second embodiment is a storage place for various data circulating in the data flow graph, and stores the actual objects such as identifiers, numerical values, character strings and dictionaries, arrays, and binary tree list structures. Has been done. The present embodiment is characterized in that the element groups constituting the system are also data tokens that circulate the data flow graph, and the data flow graph hereafter referred to as a grid, each tile in the grid, the method identifier and the grid. A class definition consisting of a collection of pairs of classes, a class definition table consisting of a collection of pairs of class identifiers and class definitions, etc. are all included in workspace 2306.

FIG. 24 is a display example on the user screen in this embodiment. On this screen, the program has already been executed, and the character string "HELLO WORLD" is displayed in the display area 2401 to indicate that the execution has been completed. The operation of each button displayed in FIG. 24 and the detailed description of the program will be described later. Only the basic components will be described here.

In 2411, 2412, and 2413, diagrams are drawn that indicate execution instruction identifiers and execution options called operands, the direction in which input data enters, and the direction in which output data is discharged, respectively. This rectangle is hereafter referred to as the "tile". Details regarding tiles are described in FIG. The tile is also rectangular in this embodiment.

2408 is an area where tiles are arranged vertically and horizontally adjacent to each other, and in the second embodiment, it is hereinafter referred to as a "grid". The grid object is an object that holds the contents of this area. The grid is given a method identifier for identification. The grid of 2408 is given the identifier "MainLine", and the name is displayed in the display area and pull-down menu 2407. In addition, the correspondence between this grid and "Mainline" is registered in the class definition data token object corresponding to the identifier "App", and the class definition identifier name "App" is displayed in the display area and pull-down menu 2414. It is displayed. The illustrated state is "the current state of the definition grid (data flow graph) of the Mainline method of the App class, in other words, the display state of the editing status. Also, as an identifier indicating the position of each tile in the grid, the column is on the left. Is indexed as A, B, C, ..., G, and rows are indexed as 1,2,3, ..., 7 from the top. Identifiers are "A1", "B2" in the order of column rows. For example, the position of the tile of 2413 is "D3". 2405 is the scale row displaying the index of the column of the tile on the grid display, and 2406 displays the index of the row. It is a scale line.

The "program" expressed on this Main Line board will be briefly explained. Tile 2411 is illustrated with instructions to cause an object with input 0 to execute a method called CONST. The default behavior corresponding to CONST is that the object of input 0 that is the execution target is specified as an option regardless of the data token of any class, ignoring the contents, and the first 4 characters "" HELL "" It is an instruction to pass the character string data token "HELLO WORLD", which is abbreviated only as "HELLO WORLD", as output data to the tile adjacent to the bottom of this tile. This action definition is determined based on the class definition of the data token object with input 0 or the contents of the superclass definition table. In the second embodiment, as will be described later, the above operation is defined and associated with the upper level class definition of the default class hierarchy. Tile 2412 is illustrated with instructions to cause an object with input 0 to execute a method called PRT. The default operation for the PRT method is to print the contents of the object with data input 0 from the tile adjacent to the top as the execution target of the PRT method in the display area of 2401. Furthermore, the input data is passed as it is to the adjacent tile below. Tile 2413 describes the execution instruction of the END method. The default behavior of the END method is to discard the data itself from the tiles adjacent to the top as input 0, which is the execution target of the method, and output nothing. In this grid program, the execution of tile 2413 discards the data, and the execution of the system ends when there is no data circulating in the entire program system. The arrows in this program indicate the data distribution route, not the control flow, and the diagram is a data flow graph. In addition, each tile in the diagram corresponds to the execution section of the data flow graph.

2402 in FIG. 24 is a push button labeled "RUN", and when pressed, execution of the set program is started. When this button is pressed, one instance of the App class displayed in 2414 is created, and for that, the Mainline method displayed in 2407 is specified as the instance of the App class created as input 0. Then, the execution evaluation method described later is called. As a result, the instance token of the App class passed as the input 0 of the argument of the execution evaluation method as the input 0 that triggers the execution is dropped on the tile 2411 at the center of the upper side of the program graph shown in 2408. The execution of the tiles that the required data arrives and becomes executable continues.

2404 is a push button labeled "NEW CLASS", which can be pressed to register a newly named class definition. Details will be described later. 2403 is a push button labeled "NEW METHOD" that, when pressed, allows you to create a new grid with a new name for the class definition currently selected and displayed in 2414. Details will be described later. The name associated with the grid can be used as the "method name" in the tile, and by creating a new named grid, the algorithm represented by that grid can be used as a subroutine method in other grids or recursively. Can be used in its own grid.

2414 is a display area and pull-down menu, and all the class identifiers registered in the class definition table are listed as selection candidates as selection candidates. The user can select a class name from this menu and the 2407 will be able to select one of the methods that the class has.
2407 is a display area and pull-down menu, and is displayed as selection candidates. All method identifiers of the selected class are listed as selection candidates. When the user selects a method name from this menu, the 2408 display switches to the contents of the grid with the selected name for editing. The 2407 doubles as a display switch and a display of the board name currently displayed on the 2408.

In this embodiment, as in the first embodiment, the grid has an odd number of tiles in both vertical and horizontal directions such as 3 × 3, 5 × 5, and 7 × 7.

2409 is an area for displaying the direction of the input data of the displayed grid. The grid receives one or more data inputs, but you can set which direction is the direction of data arrival. 2409 is the display area. In this example, T: Top, that is, it is possible to start the execution of the method called Mainline when the data arrives from above. On the other hand, each tile has 0 or more outputs, and which direction is the output is displayed in the area of 2410. In this example, Mainline does not output to the outside, so the 2410 field is blank. 2415 is an alternative pull-down menu of "ALL" or "ANY", and displays the execution start condition of the grid. That is, when this value is "ALL", if there are multiple inputs, it will not be executed until all the data arrives, and if it is "ANY", execution will start immediately if any one data arrives. It is displayed that it is a type of grid.

FIG. 25 illustrates two details of the display of each tile. 2501 in Figure 25 (a) is a reprint of the CONST method tile illustrated in 2411. 2502 is a straight line that is not an arrow, indicating that external input comes in from this direction, that is, from above. 2503 is an identifier for the input data. This is given assuming an instruction tile that has a plurality of inputs and whose result changes unless the inputs are distinguished, for example, an instruction such as subtraction or division.

2504 is the method identifier display. Here, the CONST method that outputs a constant by default is displayed. In addition, it is possible to set the name of the already registered named grid as well as the method name prepared in advance by the program execution system. Furthermore, it is also possible to specify an arbitrary undefined identifier on the assumption that it will be defined later. 2505 is a display of options for 2504 methods. Since the default CONST method does not determine what kind of constant is output only by the method identifier, specify the constant as an option. Some methods do not require options.

The outward arrow on the 2506 indicates that there is output in this direction, for the tiles adjacent below in this example. Like the input, the output is given an identifier and is displayed along the arrow like 2507.

2508 in Figure 25 (b) is a method SWITCH execution instruction tile that has multiple inputs and outputs by default. The SWITCH method is an instruction that has two inputs and two outputs by default, and if input 1 is a special identifier NIL, the data that came in as input 0 is output to output 1, otherwise it is input. Output 0 to output 0. In this default behavior, the data is ejected to either output 0 or output 1, no data is ejected from both, and it corresponds to a conditional branch that considers the data NIL as a false logical value and switches the output. Is. In the 2508, input 0 enters from the tile adjacent to the top, input 1 enters from the left, is passed down as output 0, and is passed as output 1 in the tile adjacent to the right. 2510 indicates that the input from this direction, i.e. from the left, is input 1, and 2511 indicates that the output to the right is output 1.

In 2508, input 0, input 1, output 0, and output 1 are set as top, left, bottom, and right, respectively, but in this embodiment, the input direction and output direction of each command tile are free. Can be selected and set to. Since the directions of these inputs and outputs can be set freely, it is necessary to assign identifiers to the inputs and outputs to avoid confusion.

FIG. 26 shows an extracted and deformed part of the Mainline grid displayed in FIG. 24. The position of the END instruction tile is different from that in Fig. 24, but it is equivalent in terms of algorithm representation. Here, 2609 indicates that the current display target class is App, 2607 indicates that the display of the current method is Mainline, and 2608 indicates that the condition "T" that this Mainline grid can start execution. Is displayed. In the case of T alone, if data enters from above, the board can be executed. In this example, when the RUN button of 2402 in FIG. 24 is pressed, the instance token of the data app enters from the position of 2601 on this board.

The instance token of the submitted data app is received by tile 2602 as input 0. For tile 2602, the method CONST with input 0 is immediately executed with the option "HELLO WORLD" by the execution condition check of the method CONST with input 0. As a result of execution, the token of the character string "HELLO WORLD" is passed to the tile 2603 adjacent to the bottom as output 0 of 2602. Tile 2603 is set to receive the data from above as input 0, and after receiving it, the execution condition check of the method PRT is performed on the character string object of input 0, and the method PRT of tile 2603 can be executed. Judged and executed after 2602. As a result of executing 2603, the token of the input character string "HELLO WORLD" is displayed in the display area 2401 in FIG. 24, and then is passed as it is as output 0 to the tile 2605 on the right side. Tile 2605 has END set as the method identifier 2606. Tile 2605 receives the character string "HELLO WORLD" as input 0 from the tile 2603 on the left. The END method of the string object can be executed when the data arrives at input 0, so tile 2605 is executed after 2603. As a result of executing this END, the reference to the token of the input character string data "HELLO WORLD" is abandoned. As a result, none of the tiles in this system can be executed, so the execution mechanism ends the process.

The letters T, L, R, and B can be used as the input direction symbols for the 2608, representing up, left, right, and bottom, respectively. The order of appearance of this symbol from the left specifies the input identifier. For example, in the input display of 2608 "TL" and the value of 2610 is "ALL", it means that it can be executed when the data arrives from both the top and the left, and T is It also indicates that input 0 and L correspond to input 1. If the value of 2610 is "ANY" in the same input display, it can be executed when either of them arrives as input, input 0 if the arrival direction is from the top, input 1 if the arrival direction is from the left. Associated. If only one direction symbol is specified, the grid will be executable immediately when data from that direction arrives, regardless of the value of the execution condition check box 2610.

FIG. 27 (a) is a flowchart showing the operation of the interpretation execution unit, which is 2303 of FIG. 23 in the execution engine of 106 of FIG. 1 of this programming language. When the interpreter starts, it first creates an instance of the App class as shown in 2701. The interpretation system then creates the 3x3 grid object illustrated in 2704 in Figure 27 (b), as in step 2702. The entire execution process is reduced to applying the execution evaluation procedure Eval, which is a method of the grid object, to the grid object of 2704, using the instance of App created in 2701 as input 0 as an argument token.

FIG. 28 is a default processing flowchart of the Eval procedure of the grid object class. The working structure used in this procedure is shown in Figure 29. The various working structures shown in FIG. 29 are stored in the execution environment holding unit of 2304 in FIG. 23. In the execution evaluation of the grid class, a structure called context is used as a working area. The context structure holds a reference to the grid object itself, a wait queue 2901 for tiles waiting to be executed, a wait location 2902 for output tokens of the grid output in the middle, and other data.

The grid's Eval procedure first creates a context structure in step 2801, registers itself as a reference to the grid, and performs initialization such as clearing the wait queue. Next, pass the input token passed as an argument of the Eval procedure in step 2802 to the specified tile. At this time, in step 2803, a waiter structure that holds the passed arrival data group 2903, the passed tile 2905, and the tile position information 2904 is created and registered in the wait queue.

The grid's Eval then removes the waiters from the wait queue one at a time and checks if the waiters are executable. If any one is feasible, dequeue the waiter and proceed to step 2805. If the queue is empty or none of the entries are executable, go to step 2808. Whether or not the waiter is executable is determined by performing a search using the tile method name as a key for the class definition of the input 0 token arriving at the waiter, and the executable condition of the obtained method definition. It can be confirmed by referring to the information. In some cases, input token 0 may not have arrived, but in that case, it is checked by checking the definition of any other input token that has arrived by performing a method name search. Can be realized. In either case, if the method is not defined for the corresponding token, or if it cannot be executed due to the condition value of "ALL" or "ANY" described in the execution condition of the found method definition, it cannot be executed. The removed waiter is returned to the queue. In this embodiment, it is determined whether or not the specified method can be executed for the token of input 0 that has arrived or the token that has arrived if input 0 has not arrived.

In step 2805, the input token group and the method name are fetched from the waiter fetched from the queue, and the method name and the input token group are executed and evaluated for the input token used for the executable check in step 2804. Execute the method Eval (). As a result, 0 or more output tokens are passed as the return value.

In step 2806, each token of the processing result obtained as the return value of 2805 is passed to the adjacent tile in a predetermined direction. At this time, if the waiter of the adjacent tile already exists in the queue, it is added to the arrival token storage of the waiter. This search can be performed based on the information of the waiter shown in FIG. 29 (b). If there is no waiter for the adjacent tile in the queue, create a new waiter, add it to the arrival token storage as the first arrival token there, and add the created waiter to the queue.

In process 2807, when the processing tile is at the edge of the grid and there are no adjacent tiles, it is detained in the context's output-waiting token storage 2902 only if that edge is in the output direction position of the grid definition. Tokens that come out of the edge elsewhere will either be discarded or reported to the system as an error case.

If no executable entry can be found in the wait queue in step 2804, then step 2808 prepares for the return of this procedure. The return value is a group of tokens detained in the output waiting token storage 2902 of the context, and is returned at the position corresponding to the output number. The context structure is discarded at the end of the procedure, but if there are entries left in the wait queue at this time, there may be a process to report to the system that a residual token has been detected.

FIG. 30 is a flow chart for searching the executable entry of 2804 in FIG. 28. As a result of this search process, an executable waiter entry is output, or if there is no executable entry, NULL indicating that the entry did not exist is output.

3001 checks if there are unexamined entries in the queue, even if the queue is empty. If the queue is empty or all entries have been examined, go to step 3009, print NULL and exit. Otherwise, 3002 extracts one uninvestigated entry.

Since the arrived token is registered in 2903 in FIG. 29 in the extracted entry, first check whether the input 0 has arrived. If it has arrived, the search target of the following method is input 0. If input 0 has not arrived, the input with the smallest input number among the arrived tokens is targeted. In this rule, input 0 is the highest priority candidate for the search target. In addition, the search target is selected even when input 0 has not arrived in consideration of the case where the execution start condition of the specified method is "ANY". In this embodiment, object-oriented programming is realized in which a message called a method identifier is sent to any of the input tokens. Therefore, one of the arrival tokens is selected, and the execution condition is extracted in the form of trying to apply the method to it. 3004 or 3005 form part of this target token selection rule.

In step 3006, it is determined whether or not the method definition corresponding to the specified method name 2906 exists for the target token selected by the processing of 3004 or 3005. In this determination, the search to the upper class is also included, and the processing details are shown in FIG. As a result of this determination, if the method definition search fails, it is determined that it is not feasible, the waiter being investigated is classified as investigated, and the process returns to step 3001. If the method definition is found, it matches the number of tokens arrived at 3007 with the number of inputs requested by the method definition, and the value "ALL" or "ANY" in the method definition, etc. Judge whether it is feasible or not by the judgment of. If it is determined that it is not feasible, the waiter under investigation is classified as investigated and the process returns to step 3001. When it is determined that the execution is possible, the process proceeds to step 3008, the waiter is output, and the process ends. In the processing rules after 904 during this series of search judgment processing, if input 0 has not arrived, not only one. It may be a rule that searches messages and checks execution conditions for all other arrived tokens. In the present embodiment, the token to be searched is extracted according to a predetermined rule shared with the creator of the data flow graph, the method definition is searched for it, and the feasibility is judged.

FIG. 31 is a flowchart of the search process of the designated method definition in step 3006 of FIG. The input of this process is the method name and the search target input token, and the output is either the searched method definition object or NULL indicating that it was not found. In this embodiment, the class definition has a reference to the class definition token of the superclass. The class definition of a superclass also has an attribute dictionary, a table of method names and definitions.

The method search is first performed in step 3101 on the attribute dictionary in which the instance members of the input token are registered. Each instance can override the method by giving priority to the instance member definition over the class definition. If there is an entry with the same name as the method name in the attribute dictionary, that value is output as a result in step 3106 and the process ends. If there is no definition in the instance attribute dictionary, the class definition is searched in step 3102. In this search as well, the attribute dictionary of the class definition is searched first, and if it is not found on the attribute, the default method dictionary of the class definition is searched. If there is a corresponding entry in these dictionaries in the class definition, the value is output in step 3107 and the process ends.

If there is no corresponding entry in the class definition, the class definition of the superclass of the class definition is extracted, the next search target is set, and the process returns to step 3101 to form a loop. If the superclass is not defined here, the final conclusion is that NULL is output as the method search result in step 3105 and the process ends. Here, when there are a plurality of superclasses, multiple inheritance can be realized by changing the loop after step 3101 to a recursive call to itself in the order of priority of the superclass in step 3103. Also, if the loop after step 3101 is omitted and the tip of No. 3101 is connected to 3105, the rule without inheritance can be realized.

FIG. 32 is an illustration of the structure of the data token object and the structure of the class definition object in this embodiment. These objects are stored in the 2306 work area of Figure 23. A data token object consists of a reference to a class definition object that determines the type of token and a reference to an attribute dictionary that holds unique information that is different for each instance that corresponds to a collection of instance variables. In the present invention, the class definition is also a distribution data token, and therefore the superclass definition also has an attribute dictionary.

FIG. 33 is an example diagram of the class inheritance hierarchy in this embodiment. In this embodiment, the abstract class Token, which is the top class of the class hierarchy structure and is the type of the data distribution token in the data flow graph, is one of the methods, which is a reference to the context, a method name, an option character string, and so on. It has an execution evaluation procedure Eval that returns the execution result status and output token group as the result, using the input token group as the input parameter. As a result, all tokens can be evaluated and executed by the processing system.

Next, an example of the event driving mechanism in this embodiment will be described. API mediator 2305 in Fig. 23 has a table in which the identifier of the occurrence event as shown in 3401 in Fig. 34 is used as a key and the method name and the registered object are used as values. An example of this table is shown in 3402. This is a button press event for a dialog like 3501 in Figure 35 with four buttons "ADD", "SUB", "MUL", "DIV" posted by the UI and input items for values A and B. Represents a registration table. There is an entry for each button press event, for example, when the ADD button is pressed, it indicates that the registered object is instructed to execute the method OnADD. At this time, input 0 of OnADD becomes the registered object itself according to the specifications of the embodiment, and input 1 is supplied with 3502 of the dictionary token Fig. 35 containing the item name and value set of the displayed dialog. do. In this example, the existence of input 1 is not specified, but it may be implicitly specified in the system specifications of the embodiment, or information may be specified as an additional entry in 1301. As an example of 3402, the registration objects for all four buttons refer to the common token 3403, which is the method name "OnADD", "OnSUB", "OnMUL", for each referenced entry. The entry for "OnDIV" is in the attribute dictionary. Of course, each entry in the registration table may be different as long as the value for the corresponding method name is a token that can be extracted as a search result.

Calling the procedure when an event occurs in the API mediator 2305 when the ADD button is pressed is the same as the flow chart in Fig. 27 when the execute button of 2402 is pressed. Create a context structure and enter the registered object in input 0 1 This can be achieved by creating a grid that calls the OnADD method by inserting token 3502 into the grid and executing the execution evaluation procedure Eval for that grid object. This operation is equivalent to replacing the instantiation of 601 in the flowchart of FIG. 6 with the creation of the registered object, the grid creation of 2702 with the above grid creation, and 2703 with the execution with this created grid.

In the second embodiment, in the following, in the state of event registration of 3402, 3403, and 3404 in FIG. 34, when the dialog of 3501 is displayed and each button is pressed, a message such as 3503 is displayed. Illustrate an application that displays a dialog. In 3504, the message when the ADD button is pressed is illustrated, and "OnADD" indicating that it is a reaction to the ADD button and "122" which is the value of A + B are displayed. This message is "OnSUB: -32" for the SUB button, "OnMUL: 3465" for the MUL button, and "OnDIV" for the DIV button when A = 45 and B = 77 according to the setting value of 3501. It is an application that changes to: 0.544 ”, and each numerical value changes to various calculation results depending on the input values of A and B in the dialog.

3601 in Figure 36 shows the definition of the OnADD method in the class definition of the DialogHandler class, which is a subclass of the dictionary registered as 3403. As the input specification "LT" of 3602 indicates, input 0 itself enters from the left of tile A4, which is the left entrance, and the dictionary token 3502 of the dialog information of input 1 is from above tile D1, which is the upper entrance. come in. Input from tile D1 makes three references on tiles D1 and E1. One reference is the GETI method of C2, where the value of key "A" written in the option is supplied from output 0 to input 0 of tile D2, and the other reference is the value of key "B" on tile E2. Is extracted and supplied to input 1 of tile D2. Tile D2 is an execution instruction of the "A + B" method for the object token of input 0, and the A + B method of the numerical object outputs the result of adding the numerical value of input 1 to itself to output 0. Similarly, "A-B", "A * B", and "A / B" are provided as methods for subtraction, multiplication, and division of numerical objects.

References from the remaining tiles F1 reach F3 and G4. Both F3 and G4 are CONST methods that output options. The CONST method is defined in class T and can react to most objects that are subclasses of it. As a result, F3 outputs the character string "OnADD" to the output, and G4 outputs the character string ":" to the output.

For tile E4, "A + B" is specified in the method, but input 0 is the character string "OnADD". In the example system, the "A + B" method is uniquely defined in the character string class, and the operation of concatenating the character string of the token of input 1 to itself, which is input 0, is defined. In E4, input 1 is a character string, so it is concatenated as it is, and the character string "OnADD:" is supplied to input 0 of tile D4. D4 is also A + B for the character string, but it differs from E4 in that input 1 is the output of D2. However, since the value of a numeric object can be converted into a decimal representation string in the example system, the string token "OnAdd: 122" is generated from D4.

Tile D5, which receives the output of D4, is instructed by a method called ALRT. ALRT displays a string representation of an object with input 0 in a modal popup dialog like 3503, waits for the user to close the dialog, and passes the value of input 0 to the output. Since ALRT is also defined in class T, objects of most of its subclasses are set to be executable.

When the popup dialog is closed, D6's END is executed, but as mentioned above, END only discards the input, and the series of data flow from D1 ends here. Also, since the scheduled operation has been completed so far, input 0 that came in from the left of 3601 may be abandoned without using it, and in this connection, input 0 is immediately abandoned on tile A4. ing. As a result of these two ENDs, there are no executable tiles in the grid 3601, the event handler OnADD ends, the Eval for the grid issued by the API mediator 2305 also ends, and the event reaction process itself is completed.

If you register the above grids individually as OnSUB, OnMULL, and OnDIV, the application will be completed, but each has the method name of 3603, which is tile D2 in 3601, and the option value of 3604, which is tile F3. Only the difference is different, and it is possible to copy the definition based on the grid definition of OnADD and rewrite only the above difference part and register it, which is different from programming manually separately. In the following examples of this example, the program for rewriting definition registration of this alternative method will be illustrated.

Figure 37 shows the definition of the Init method of the DialogHandler class, which is the method that leads the rewriting. This method is called from the registration method before registering DialogHnadler in Table 3401. The timing may be from the constructor of the DialogHandler class. Init takes itself on input 0, defines OnSUB, OnMUL, and OnDIV methods, and outputs an instance of itself with these added from output 0. This method is represented by a 5x5 grid, so columns are up to E and rows are up to 5.

The method Init calls the method AddOn defined in DialogHandler as shown in Figure 38. AddOn takes the DialogHandler for input 0, the method string that replaces tile D2 for input 1, the option string of F3 for input 2, and the string of the XXX part of "OnXXX" that is the basis of the method name, and corresponds to it. Output the DialonHandler object with the "On ~" method registered. In the Init grid, OnSUB is registered with tile C2, OnMUL is registered with C3, and OnDIV is registered with C4, and in the CONST of column B where the input of each tile is, "SUB", "MUL", "DIV" are , "AB", "A * B", and "A / B" are supplied in the D column that supplies the replacement operation method, respectively. As an extension example of this application, even if 1401 buttons are added and the surplus button MOD (corresponding operation "A% B") and the greatest common divisor button GCD are added, Init can be extended. In this example, there is no class that has a direct method to calculate the greatest common divisor, but the method GCD may be user-defined for the numeric class, and a tile for calculating the Euclidean algorithm may be applied as the value. The instructions supplied in column D do not have to be system-defined methods.

Figure 38 shows a method AddOn that copies and edits the OnADD grid and adds it to the DialogHandler. In this definition, the input direction is "LTR", the input position is from A4 on the left, the method name of input 1 is from D1 above, and the operation instruction method string of input 2 is from G4 on the right. For input 0, after the grid corresponding to OnADD is fetched from the object by the GETI method of A3, the DUP method that creates a "shallow copy" of the grid object, which is a subclass of this dictionary class, is executed on tile A2. The character string of input 1 is a group of tiles in the area of E1-F2, and the character string of "On ~" is created and supplied to D6 via JCT of C2, D4 and E5. In addition, the arithmetic method character string of input 2 is supplied to D5 via JCT of E5.

The method JCT is a method defined in class T with 2 inputs and 2 outputs as shown in Fig. 41, and passes input 0 to output 0 and input 1 to output 1, respectively. This method can create data flow intersections on the grid by setting inputs and outputs 0 and 1 as in tile E5 in Figure 17. Due to this JCT tile of E5, the character string of "On ~" of input 0 straddles the path of input 1 from E4 to E6, and the character string of the operation method name from G4 straddles the path from F5 to D5. Reach each.

RepLBL of tile D4 in Fig. 38 is a method defined and registered in the grid class as shown in Fig. 39, and replaces the option of tile F3 of its own grid with the character string "On ~" that comes in from input 1. The resulting grid is output from output 1. Similarly, RepOP of tile D5 is also a method defined and registered in the grid class as shown in Fig. 40, and replaces the method instruction of D2 of the grid of input 0 with the character string of input 1. By applying these two methods continuously on D4 and D5, the input 2 of D6 will contain the grid for which the replacement has been completed.

The PUT of tile D6 in Fig. 38 is system-defined in the dictionary class, and like PUTI, it writes a value to the dictionary with input 0 and outputs the written dictionary to output 0, but with PUTI Unlike, the key is passed as input 1 from the outside, and the value to be written is supplied from input 2. As a result, in D6, the rewritten and edited grid is written to the instance of DialogHandler using "On ~" as a key, and the output is passed to D7, and the output is output from D7 as the final result of this AddOn method.

Figure 39 shows the definition of the RepLBL method defined in the grid class. The input direction of this method is "LT", and the grid of input 0 is from A4 on the left, and the character string such as "SUB" which is the material of the character string "On ~" which is input 1 is D1 above. Is entered into this method. First, from the grid entered from A4, the tile at position F3 is taken out by GET of A3 and duplicated at A2. This RepLBL attempts to replace the optional string of the duplicated tile object with input 1 and write it back to F3 of the original grid that came in from input 0. The value of the key OPTION containing the setting value of this tile option is rewritten with PUT of D2, the tile is overwritten to F3 with PUT of C5, and output as the result of RepLBL from D7. In the definition of RepLBL in Fig. 39, it is possible to change the GET of A3 to GETI and the PUT of D2 and C5 to PUTI, thereby simplifying the graph.

In tile D2 in Fig. 39, among the attributes of the grid duplicated in A2, the PUT method that rewrites the contents of the option registered in the key OPTION to the value passed as input 1 of RepLBL via tile D1 is executed. ..

Figure 40 shows the definition of the RepOP method defined in the grid class. The operation is similar to RepLBL, the tile at position D2 is extracted from the grid entering from the left A3, a copy is made, and the method name written in the OPNAME entry in the attribute dictionary of the tile. The value of is replaced with the character string of input 1, and the rewritten tile is overwritten and written back to D2 of the original grid. D2 Tile is taken out by tile A2, tile copy is done by A1, tile method name is rewritten by C1, and overwrite write back to the grid is done by PUTI of tile C3. The simplification of the definition by adopting PUTI and GETI mentioned above is done here, and as a result, the size of the definition is as compact as 5x5.

By providing a programming language for graphical representation that incorporates the above event-driven specifications, it is possible to directly describe response processing to humans and external systems that intervene in device control and operation. In addition, by introducing an object-oriented language specification and a specification that handles most system elements as distribution data tokens, even in programming of the above-mentioned restricted editing environment in a diagram format, the program can be modified or newly created by the program. Such an improvement in writing ability is realized.

The present invention enables programming with only a touch panel. As a result, by changing the physical mechanism of the touch panel, any device equipped with a display device can be made programmable with almost no change in the original outer shape. In particular, it can be used as a programming means for smartphones, tablets, or smart speakers that normally do not have a keyboard. This makes it possible to easily create new applications by controlling and combining a plurality of applications installed on these devices. Further, since the input device only needs to have the above-mentioned position designation and two types of instruction functions, it can be used as an environment in which a person with a handicap can easily program.

In addition, since programming itself originally contains puzzle-like elements, it can be applied as a puzzle game on smartphones and tablet terminals.

In addition, it can be expected to have the effect of enabling the practice and learning of object-oriented programming even on devices where the keyboard does not exist in the default environment.

101 Whole device
102 Controlled equipment
103 Start / stop switch
104 timer
105 Equipment control interface
106 Program Execution Engine
107 touch panel
201 Output display area
202 Program execution start button
203 Create new named board button
204 Named board delete button
205 Board edit operation button
206 Tile definition External save load button
207 Display target board selection menu display area
208 Named board display area
209 Input condition display area
210 Output direction display area
211 CONST tile
212 PRT tiles
213 END tile
301 CONST tile
302 Input 0 display line
303 Identification display of input 0
304 Tile instruction display
305 Tile option display
306 Output 0 display line
307 Identification display of output 0
308 SWITCH tile
309 Tile command display
310 Identification of input 1
311 Output 1 identification display
401 Named board MainLine full view
402 CONST tile
403 PRT tile
404 tile instruction display
405 END tile
406 Tile command display
407 Name display of named board
408 Named board input condition display
601 Name display and selection pull-down menu of the named board
602 Named board input condition display
603 INPUT tile
604 Factorial calculation tile n!
701 Name display of named board n!
702 n! Output direction display
703 n! Input condition display
704 COPY3 tile
705 PASS tile
706 CONST tile
707 SWITCH tile
708 GT tile
709 COPY2 tile
710 n-1 tile
711 n! Recursive call tile
712 A * B tile
713 PASS tile
714 MRG2 tile
715 CONST tile
801 INPUT tile instruction name
802 Input from the right 0
803 Left output 0
804 Input from the right 0
805 n! Recursive call to tile
1101 Initial setting dialog for newly named board
1102 Newly named board name input item
1103 Newly named board size selection menu
1104 Newly named board input condition setting input item
1105 Newly named board output direction setting input item
1201 Select tile enlarged display edit dialog
1202 Enlarged view of selected tiles
1301 Tile instruction setting dialog
1302 Instruction selection menu
1303 Command option setting input item
1401 Tile command selection menu expansion display
1402 Choices to reset tiles
1501 Area of the entire tile
1502 Zone 1 near the center
2001 Program Execution Engine
2002 UI operation processing department
2003 Interpretation Execution Department
2004 Execution environment maintenance unit
2005 Predefined tile holder
2006 work area
2201 I / O not set Initial state
2202 State after input 0 setting
2203 State after input 1 setting
2204 State after setting output 0
2205 Input 1 State after canceling settings
2206 Input 1 State after resetting
2207 State after setting output 1
2301 Program execution engine
2302 Cooperation with touch panel 107
2303 Interpretation Execution Department
2304 Execution environment processing unit
2306 work area
2307 Cooperation with device interface section 105
2401 Output display area
2402 Program execution start button
2403 Create new method button
2404 Create new class button
2405 Column index display row
2406 Row Index Display Column
2407 Display target method selection menu and display area
2408 Grid object display area
2409 Input direction display area
2410 Output direction display area
2411 CONST tile
2412 PRT tile
2413 END tile
2414 Display target class selection menu and display area
2415 Execution start condition selection menu and display area
2501 CONST tile
2502 Input 0 display line
2503 Identification display of input 0
2504 Tile command display
2505 Tile option display
2506 Output 0 display line
2507 Identification display of output 0
2508 SWITCH tile
2509 Tile instruction display
2510 Identification of input 1
2511 Output 1 identification display
2601 Full view of MainLine method example of App class
2602 CONST tile
2603 PRT tile
2604 Tile command display
2605 END tile
2606 Tile command display
2607 Method name display
2608 Method input direction display
2609 Class name display
2610 Display of execution start condition
2704 Start of execution Initial input grid
2901 Wait queue entry for execution waiter
2902 Waiting for output token temporary storage entry
2903 Arrived token temporary wait entry
3501 Example Application Input Dialog
3502 The data token passed to the event handler when the 3501 button is pressed
3603 Pop-up message dialog displayed by the event handler
3504 pop-up message
3505 ADD (addition instruction) button
3601 3505 Grid display of event handler example when button is pressed
3602 Grid 3601 input direction display
3603 Arithmetic tile to be edited
3604 Message generation tile to be edited

Claims (11)

As the representation format of the data flow graph, a tile format including one execution instruction identifier, the number and direction of input data, and the direction of output data, and a format showing data exchange between adjacent tiles are adopted and used. A data processing apparatus comprising a means for a person to directly create and edit a diagram representation of an arrangement of the above format, store the illustrated representation of the edited arrangement in the internal representation format, and then execute the internal representation format. The data flow graph is assigned an identifier, and the data flow graph is used as an instruction definition, and the assigned identifier can be used as an instruction identifier in the tile format representation as one of execution instructions. Data processing device. When the execution instruction definition by the data flow graph can be given an identifier having an order to a plurality of input / output terminals, and the input / output direction at the time of definition and the input / output direction at the time of use are different. , The data processing apparatus according to claim 1 or 2, characterized in that the terminal identifiers are matched. The data token object circulating in the data flow graph has a class definition having a method definition and an instance-specific information group, and at least as a default class, an identifier, a numerical value, a character string, a logical value, a binary tree list, and an array. , Dictionaries, data flow graphs, tile format representation data, built-in operation objects, class definitions, class definition registration tables, global variable registration tables, run-time parameter lists, and other elements that make up the processing system, and when the processing system is running The data processing apparatus according to any one of claims 1 to 3, which contains necessary information in an inheritance hierarchical structure and can be distributed in the data flow graph. All the distributed data token objects are provided with an execution evaluation procedure as a method, which takes an execution instruction identifier and an input token group included in the tile format representation as parameters and outputs an output token group which is a processing result as a result. In the tile format representation, for one token extracted by a predetermined rule from the arrived tokens, the method corresponding to the execution instruction identifier is searched, the feasibility is checked, and the method is executed. The data processing device according to any one of claims 1 to 4, which is characterized. A table is provided in which an event that occurs in response to a change in the state of the controlled device is used as a key, and a data token that is registered in advance corresponding to each event is used as a value. Any one of claims 1 to 5, wherein a means for calling an execution evaluation method is provided with a parameter group associated with an event occurring as an input data token group for a predetermined defined content. Item data processing device. The data processing device according to any one of claims 1 to 6, which divides each tile in the diagram into a plurality of sections and executes different editing operations for user operations on each divided section. .. The device control device according to any one of claims 1 to 7, wherein control instructions for each function of a predetermined controlled device can be set as the execution command. Data processing that employs a tile format that includes a representation of one execution instruction identifier, the number and direction of input data, and the direction of output data, and a format that indicates the exchange of data between adjacent tiles as the representation format of the data flow graph. A data processing method in which a user accepts editing of a diagram representation of an arrangement of the above format, stores the illustrated representation of the edited layout in an internal representation format, and then executes the internal representation format. The data token object circulating in the data flow graph has a class definition having a method definition and an instance-specific information group, and at least as a default class, an identifier, a numerical value, a character string, a logical value, a binary tree list, and an array. , Dictionaries, data flow graphs, tile format representation data, built-in operation objects, class definitions, class definition registration tables, global variable registration tables, run-time parameter lists, and other elements that make up the processing system, and when the processing system is running The data processing method according to any one of claims 1 to 9, wherein necessary information is included in an inheritance hierarchical structure and can be distributed in the data flow graph. All the distributed data token objects are provided with an execution evaluation procedure as a method, which takes an execution instruction identifier and an input token group included in the tile format representation as parameters and outputs an output token group which is a processing result as a result. In the tile format representation, for one token extracted by a predetermined rule from the arrived tokens, the method corresponding to the execution instruction identifier is searched, the feasibility is checked, and the method is executed. The data processing device according to any one of claims 1 to 10, which is characterized.

Images