# HG changeset patch # User Sean Halle # Date 1379095498 25200 # Node ID 5c0400b5ae595592e09c76169559aaf88863f02f # Parent b0de2e24054e36e9d4deb2d56034a1067f9a13e7 Unknown changes.. committing to get them captured diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Dc_26___Syntax_Graph__CTOS_to_GUI_and_Custom_Syntax_Design.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Dc_26___Syntax_Graph__CTOS_to_GUI_and_Custom_Syntax_Design.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,21825 +0,0 @@ - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - tokenType - state tokenType allowed inside each box -- - tokenType is more than just visual, a - tokenType exists for each type of thing can - be displayed.. - -- note that there's one tokenType, italic, for a - variable that is an input, and a different - tokenType for a variable that is a - - - variable.. whereas the italic-input-variable - will be replaced (an italic-input-variable - - - -- there is a tokenType for integers, a tokenType - for dimension that can be placed in the - index position of a tensor, a tokenType for - variable, a tokenType for input, a - tokenType can be defined to indicate any - - that tokenType can be used, along with - restrictions on the characters (ie, one can - define a tokenType that can only have the - integers from 1 to 50).. or can define a - tokenType that one must query a processor, - during evaluation of a grammatic sentence, - to find out what the allowed character- - values are (for example, ask the particular - TensRep what is its working dimension, or - attach the dimension as a value to the - tensor-phrase, and make the tokenType - only take values from 1 to that dimension - --> this would be compatible with the way - Gabe wants to use Tensors for his electron- - states thing, where each tensor has a - different dimensionality == number of - allowed states or something like that. - - - - - - - - - - - - nodeType: commandRoot - commandName: TensRepOuterProd - IndexedTensRep - Defining Custom - Tensor Notation - - - - - - - - - - IndexedTensRep - - - - - - - - - - LH - RH - - - - - commandPatternName: generate - resolvesTo: IndexedTensRep - - - - - - - - - - nodeType: boxPhrase - TensorIndex - - - - - - - - - - TensorIndex - - - - - - - - - - Index1 - IndexN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . - TensRep - - - - - - - - - - TheTensRep - - - - - - - - - - - - - - - - - name. Then use the standard GUI gesture to - - - concatenated to the names. - Both AbsTens and TensRep use the same - TensorIndex - syntaxDataType: IndexedTensRep - A child is added via a GUI gesture, then a name for it - is entered. The arrow and the box it points to are - automatically popped up. - Each child box is labelled with a syntaxDataType. A - drop-down list is available that has all the known - syntaxDataTypes. It is important to remember that - a syntaxDataType is not a data type, and doesn't - define a data type. However, each syntaxDataType - is named the same as a corresponding data type. - The syntaxDataType appears in the syntax tree in - the position that a variable of that data type - appears or a command that resolves to that data - type appears. - So, the LH child could be, for example, another - TensRepOuterProd command OR an - IndexedTensRep variablePhrase, both of which are - syntaxDataTypes - langType is where the language-type of the phrase is - stated. This node defines what something of the - - The nodeType, langType, commandName, - commandPatternName, and produces are all standard - - are part of the OS Interface standard. - A GUI gesture is used to pop into existence a - - in the box, and a drop down list is available with - the standard node types, accessible via key - - - of a web page. - The node type determines the other fields in the box. - Those also have drop-down lists available - The boxes are not seen during use of the custom notation. - They are only seen while defining the syntax tree elements - that the editor will create in response to commands coming - from the GUI. - The GUI actions described in annotations here are actions - that happen during the syntax-tree element definitions. - Other GUI actions will happen when creating equations that - use the custom notation. - A boxPhrase consists of a box plus a number of operators - that take the box as input. The operators may be defined - to apply in any sequence or together as a collection or sub- - collections. However, the collection of operators must - only take the one box's contents as input. The data type - that the box's contents resolves to must be stated, and the - data type of the result of the entire collection of operators - must be stated. If not all operators have to be applied at - once, then the result of applying only a few is another - boxPhrase of the same type, but with fewer children. - This is a bit confusing because a boxPhrase is a syntax tree - node type, not a data type that flows between processors. - However, because of the requirement of partial evaluation - down to primitives before translation, one can act as - though a boxPhrase were a data type that flows between - processors. In fact, one can partially fill in a boxPhrase - and send that as an input. The boxPhrase must resolve, - once all children have been filled in and all the operators - have performed, to the data type of whatever box the - partially filled boxPhrase has been placed in. - For example, a pattern-function that takes an - IndexedTensRep may have an IndexedTensRep that has - empty positions (displayed in the equation as boxes) - placed in one of its input positions, as long as the pattern - fills in the empty positions, so that partial evaluation can - reduce all the way to primitives. - Also, boxPhrases can be nested, so that the result of applying - one subset of operators is the input to a further set of - operators. - During use, a box can have placed in its position a - boxPhrase, a commandRoot, a name (where a - name appears as a variable in an equation), or a - constant (of the box's type). - A boxPhrase can be placed in the position of a box - that takes such a boxPhrase. Doing so implies - that the operators of the phrase should not be - evaluated until after the boxPhrase is substituted - into the box's position, during partial evaluation. - A boxPhrase can also be placed inside a box whose - data type is what the boxPhrase results to. In this - case, the partial evaluator is free to perform the - operations of the phrase before or after replacing - the box with the phrase, whichever is most - convenient for the translator. - IndexedTensRep is actually an interesting example of a - boxPhrase. During use, the children-boxes can have placed in - their position variables, or abstractIndexes, or integers from 1 - to dimension. - The behavior is different depending on what is in the position of - each child box in the syntax tree. - If it is a variable, then there is no behavior, this is just a symbol - used in the definition of a function-pattern to indicate - matching between LHS and RHS. Each match becomes an - - If it is an integer, then the operation is a selection. - If it is an abstractIndex, then the syntax tree is searched for - matches. Any pair of matching abstractIndexes are replaced - by an operation on the TensRep data structure that the box-of- - the-boxPhrase resolves to. This operation is performed at run- - time. It iterates from 1 to the dimension of the pair of - indexes. At each value of iteration, both matching - abstractIndexes are replaced by the iteration value and a - selection with that pair of index values is performed. The - result of selection is added to a running sum of the selection - results. That sum is the final answer. (note if not all the - abstract indexes match up in some pair, then the result will be - a TensRep that still has multiple indexes.) - resultDataType: TensRep - - - - - - - - - - - - - - - - - - - - - - CTOSSpace - - - - - - - - - - - - - - - - - - - - - - - ExternalTunneller - - - - - - - - - - - - - - - - - - - - - - - Name Searcher - - - - - - - - - - - - - - - - - - - - - - dataHolder1 - - - - - - - - - - - - - - - - - - - - - - - dataHolder2 - - - - - - - - - - - - - - - - - - - - - - - dataHolder3 - - - - - - - - - - - - - - - - - - - - - - - CD-ROM - (Appears as an - External processor) - - - - - - - - - - - - - - - - - - - - - - - Authenticator - - - - - - - - - - - - - - - - - - - - - - - Creator - - - - - - - - - - - - - - - - - - - - - - - Importer-Exporter - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Other CTOS Instance - - - - - - - - - - - - - - - - - - - - - - - Web Server - - - - - - - - - - - - - - - - - - - - - - - - - FooBarWorkSpace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //images from Hubble - Format: RGB - - Date created: Jan 23, 2006 - - - - - - - - - - - - - - - - - - - - - - - - MyEqns - - - - - - - - - - - - - - - - - - - - - - - - - - - - - receive processor - - - imageHolder - - GabeImageProcessor - - - - - - - - - - - - - - - - - - - - - - Integrate - fn - result = - result - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - x - - - - - - - - - - fn dx - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Creator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Translator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - receive processor - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //Predicted Images - Format: Foobar - - Date created: Jan 24, 2006 - imageHolder - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Creator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Translator - - - - - - z := 22 - x = foo( x, y ) + z - x - - bar - - x - - y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FooBarProgramSpace - IntegrateManipulatorProgramSpace - - IndexedTensRep - - - - - - - - - - nodeType: boxPhrase - TensorIndex - - - - - - - - - - TensorIndex - - - - - - - - - - Index1 - IndexN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . - TensRep - - - - - - - - - - TheTensRep - - - - - - - - - - - - - - - - syntaxDataType: IndexedTensRep - resultDataType: TensRep - - IndexedTensRep - Modifier - modifyCommand: addIndexedTensRep - - - - - - - - - - nodeType: leaf - syntaxDataType: TensUpperIndex - - TokenType - TensDimension - TensAbsIndex - syntaxBaseDataType: TensIndex - modifyCommand: addTensUpperIndex - - - - - - - - - - nodeType: leaf - syntaxDataType: TensLowerIndex - - TokenType - TensDimension - TensAbsIndex - syntaxBaseDataType: TensIndex - modifyCommand: addTensLowerIndex - The syntaxBaseDataType is similar to syntactic sugar for - putting an OR list inside the child boxes of - IndexedTensRep - Also, remember that this specifies what the syntax tree will - look like, this is not an entry in the syntax tree itself. In - the actual syntax tree, there will be either an integer or a - letter in the node. Here, have to say that either of those is - okay to put in this position (TensDimension is a - TokenType that can have as its characters an integer from - 1 to the number of dimensions that the TensRep this - index is tied to has. - A TensRep is a data structure. So in the spec-of-the-syntax- - tree, there is no node for one, there is only a node that - - This notation here is what the programmer enters when - defining custom notation. Each box states an EMPTY - syntax node that gets added to the syntax graph in - response to the command. The contents of the box state - the TYPE of things that can be placed in the node by - GUI gestures. This information is used by the Visualizer - to generate GUI grammar that it adds to the - DisplayElements it sends to the Display - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GUI - Node: TensUpperIndex - Node: TensLowerIndex - TensIndexColumn - This specifies what the - visualizer is to produce to - represent the stated node - This specifies new GUI gestures that the - srcWindow is to recognize, plus the command to - be sent to the editor as a result of one of the - gestures - The modifier keeps track of the - insertion point - and - uses it to choose where to put the node or value. - When the editor receives this command, it will give an - error back to the GUI if the insertion point is in the - wrong place. - Also, after adding this node, the insertion point will - automatically be moved to this node. Thus, the next - - else a move-insertion-point followed by some other - command. - A token is a string of characters plus an indication of the - tokenType.. so, a function-parameter can have the exact - same characters as an expr-name, but they are displayed - differently and interpreted differently by the translator. - The function-parameter-token indicates that the tokenType - is function-parameter-tokenType, likewise the expr-name - comes in a token that indicates expr-name-tokenType - The function-parameter is displayed italic, while the expr- - name is displayed normal (normal is the default expr- - - - - serves better.. - Menu:Tensor, Entry: UpperIndex - - send: addTensUpperIndex - keySequence: /TensUpperIndex - To Do s: - 0) specification of syntax data structures: - -- what fields each has - -- the purpose of each field: how it is used by processors: Visualizer, Display, - Modifier, ReWriter, Primitive Processors - -- the valid contents each field can hold - -- what each content causes each of the other processors to do: V, D, M, RW, PP - 1) specification for one visualizer. The spec says: - -- what DisplayElements the Visualizer should generate, for each given - SyntaxNode - -- how to position the DisplayElements on the canvas - -- how to scale the DisplayElements - 2) specification of how a programmer states the grammar. - -- EQNLang's initial grammar is stated with the same terms-of as grammar of - custom syntax - -- The grammar is stated in visual terms-of. The grammar is stated as what GUI - gestures are allowed when a given link-end is focused-on, or when blank - canvas is focused-on. - - (look at issues about grammar, about how editor tells GUI when invalid commands have come in, - or an invalid order, like trying to move on before finished) - - Grammar of the visual-elements structure itself, separate from syntactic structure and semantic - structure. Eg, have boxes for each column of tensor indexes, and have that composed of an - upper and a lower: have to indicate can only have either an upper or a lower - 3) specify translation of GUI gestures to ModifyCommands - -- what information must be included with each GUI gesture sent to the Modifier - 4) specify the modification to the syntax graph caused by each modifyCommand - Examples: - -] GUI gestures: describe a context, describe what programmer does, state the - GUIGesture data-structure that goes from Display to Modifier as a result. - -] State the modify command each gesture plus context is translated into - --> Show the code that the programmer enters to cause that translation. Draw the - visualization of the Translator code. This is what the programmer sees on - their Display as they specify how to translate GUI gestures into modify - commands - -] State what the example modify command does to the syntax graph. Draw a - partial syntax graph before and after the command. This includes the - syntaxNode data-structure and the values in each field - --> Show the Modifier code that specifies the behavior of that command. IE, - draw what the programmer sees on their Display as they specify how the - Modifier is to carry out the behavior of the modify command. - -] State the DisplayList the Visualizer generates for the new syntax graph. Show - the values in each field of the DisplayList. Show the indication of insertion - point. Show the GrammarElements that state which GUI gestures are valid - from each node and from each empty link. - --> Show the code that specifies how the Visualizer is to translate the added - syntax node into DisplayElements. This is the Visualization of the code the - programmer sees on their Display as they write the Visualizer code. - -] Show the Visualization of the modified syntax graph - Palette: Tensor, Icon:<vector graphic> - The dashes indicate that it is a visual node but it doesn't display - Full Sequence of Custom Syntax - Editing Session - : - The sequence of events, starting with GUI gestures, that builds an expression in a custom syntax, including the sub-tree - being sent to the command-generator, a new syntax-tree being generated and added to the programSpace, and - the name of that newly generated command being sent back to the editor and inserted in place of the original - - -] User is sitting at a machine, invokes the local-to-that-machine sequence to create a CTOS GUI. This GUI is a - program running locally on the machine under the local OS. It is coded to know the protocol for connecting to - and communicating with a CTOS instance. This GUI can create several Displays. Each Display can specialize to - many kinds of behavior. A Display is a window that is connected to the CTOS Instance. Each Display has one - processor that has that Display's behavior-token. The Display specializes its behavior to the processor that holds - its behavior-token. For example, if a srcHolder that holds EQNLang source has the behavior-token, then the - Display has an icon palette that is specific to EQNLang srcHolders, and it has mouse-menus that are specific to - EQNLang srcHolders, and so forth. That same Display can have its behavior-token moved to some other Holder - or Space processor, in which case its icon palette and mouse-menus and other behaviors will change. The top- - level processor of the CTOS Instance is a CTOSSpace processor, which often holds the behavior-token for at least - one Display that opens upon successful authentication by the user. - -] User is presented with a list of known CTOS instances in a dialog, with a way to specify or navigate to more. User - picks one. - --> A Display is created and its behavior-token is given to the top-level (CTOSSpace) processor of the chosen CTOS - instance. - -] User is challenged inside the Display and performs authentication - --> Triggered by successful authentication, a hierarchy of visualizers is created, one inside each visualizable processor - that is visible to the authentication. (or, more likely, just inside a default set of initially visualized processors, - maybe remembering what was visualized the last time this authentication was connected to this CTOS Instance). - This hierarchy generates a visualization of the CTOS Instance and sends it to the CTOSSpace specialized Display. - --> The DisplayList generated by the visualizer hierarchy is painted in the CTOSSpace specialized Display.. - -] User focuses on a srcHolder in the Display and invokes gesture that creates a new Display whose behavior-token is - given to the focused-on srcHolder. - ==== - sent to the srcHolder, which modifies the meta-data of the syntax-tree node that has the focus. The editor also looks for - the sub-node that had the insertion point most recently, and marks that node as having the insertion point. - - --] The visualizer notes the changes in the meta-data and sends a diff to the srcWindow. - - --] The srcWindow receives the diff and redraws the thing that has focus and the thing that has the insertion point. - - The user now sees the visual cue of where the focus and insertion point are. - 2) User enters zoom gestures and pan gestures to get to a section they want to modify - - --] focus and pan are completely handled by the srcWindow. The srcWindow receives a graph of visualization objects. - Each object states a size plus a position relative to other objects. These positions are all on a canonical grid. The - srcWindow keeps a zoom factor that is the ratio between canonical distances and screen-pixel distances. The - srcWindow also keeps a clip-window that is what gets painted up on the screen. Pan moves the clip-window - around and zoom changes the size, in canonical units, of the clip window. Then the clip window contents are - multiplied by the zoom factor to give pixel-unit sizes, and the result is drawn in the paint area of the srcWindow. - 3) User pulls down the Tensor palette and selects the icon for the outer-product command - - --] The GUI was told what command to send to the srcHolder for this particular icon when the Tensor Custom - Notation Package was loaded into the GUI. This command is sent to the srcHolder's editor. - - --] The editor was told what syntax-tree-node to add for this command when the Tensor Custom Notation Package was - loaded into the GUI. The editor adds this node, with all empty children and attribute fields. The node is placed - where the insertion point was and the insertion point is moved to the first child of the command node. - - --] The visualizer knows what visual elements to send as the visual representation of the newly added node. It was told - what visual elements to use by the Tensor Custom Notation Package. It sees the new node added by the editor and - generates a tree of visualization elements that gets rendered by the srcWindow. The user sees the command- - - 4) The user then goes about moving the insertion point with arrow keys or mouse or other shortcut keys. At each point, - they do GUI gestures, to enter more nodes or to enter tokens (a name is a token). The user has GUI gestures - available to indicate the tokenType (pull-down list, icon, menu item, shortcut key, key-sequence). - At some point, all the children of the command-node have been filled in. At this point, the editor sends the command- - sub-tree to the programSpace, with the command to give it to the srcHolder-type's-custom-processor called - commandGeneratorProcessor. - That is, when a srcHolder is added to a programSpace, that srcHolder is asked for the name of the spec of any custom - processors the srcHolder wants the programSpace to make. The programSpace takes the specs and makes - processors from them, then hands back the name of each created processor (such a created processor can be a - spawner). - The EQNLang srcHolders have the spec of a CommandGeneratorGenerator processor. This processor is created by the - programSpace, if it doesn't already exist (if there is another EQNLang srcHolder already in the programSpace, - then the commandGeneratorGenerator will already exist). Next, any custom notation packages that the newly - added srcHolder requires are loaded in. - The srcHolder for EQNLang is specialized especially for EQNLang. Part of the specialization is that each keeps a list - of all customization packages that are used by any of the nodes inside that srcHolder. When the srcHolder is - added to a programSpace, or when a new notation package is loaded into the srcWindow of a srcHolder, then - some stuff happens: The customization package includes the specs of custom-command-generators. These specs - are sent by the programSpace to the CommandGeneratorGenerator. The CommandGeneratorGenerator creates a - new processor out of each spec. Thus, the commandGeneratorGenerator knows about one commandGenerator for - each kind of custom-command node that is in any of the EQNLang srcHolders that are in the programSpace. - want this whole system to be generic. So, no matter what language, the srcHolder for that language is invited to give - specs to the programSpace and have the programSpace turn those into processors and give back the names of - those processors. Thus, the commandGeneratorGenerator is created via a generic mechanism. The programSpace - has nothing custom about it that was needed for the commandGeneratorGenerator. The programSpace only has - - srcHolder. - Now, when a new custom-command-node is finished, then its sub-tree is sent by the editor to the - commandGeneratorGenerator, which hands the tree off to the commandGenerator for that type of node. The - commandGenerator has all the information it needs within the sub-tree. It performs whatever its code specifies, - - tree. The new from-Into tree is given some randomly generated name. The name is sent back to the srcHolder that - sent the custom-command sub-tree. That srcHolder then removes the entry in the original custom-command sub- - - The commandGenerator also hands the from-into tree to the programSpace to be added as a new library srcHolder. - Now that custom-command node is just like any other node that has the command-name of a from-into tree. - Tensor Outer Product - Command Generator - Need: to know how many indexes - What it does: takes two TensReps, produces a TensRep that has as many indices as the - sum of the indices of the two input TensReps. - The value of the outer product is: take any valid replacement of abstract indices with - integers, for all indices of both TensReps being multiplied. This will select a single - cell from each TensRep being multiplied. The product of those two cells is the - contents of the cell selected by the same substitution of abstract indices with integers - performed on the product TensRep. - So, a simple algorithm is to do a series of nested FOR loops. One FOR loop for each - index of each TensRep. The innermost loop's body takes the index-var values from - the outermost loops and uses them to access one cell of the left-most TensRep's - multi-set. It then takes the values of all the inner-most loops and uses that set to - access one cell of the right-most TensRep's multi-set. It multiplies the contents of - the two cells, then puts that value into the cell accessed by the values of all the - index-variables on the result TensRep. - Another way to state this is with invariants: - state the boundaries for each index-position, and state that the result-cell receives the - product of the two multiplied-TensRep cells: - R = A * B - 0 < j < 4 - 0 < i < 4 - 0 < k < 4 - 0 < l < 4 - 0 < m < 4 - 0 < n < 4 - l m - n - i - j - k - i - j - k - l m - n - Now, when a user enters a Tensor Outer Product, are restricting it to only take - TensReps as inputs, not AbsTens nor AbsTensFields nor TensRepFields. - There can be any number of indices, and in any order of raised and lowered. - Also, TensRep is a data structure that consists of a multi-set (a multi-set is a primitive - of the language), plus a vector indicating raised or lowered for each index-position - (ie, contravariant or covariant), plus the dimensionality of each index-position (in - general a TensRep can have a different dimensionality for each index-position. - Gabe uses this in his Tensor notation for energy states of bound electrons). - So, the command generator will examine the index-positions of each input to the outer- - product command. For example, the user enters: - R = A B + I - - - - - - - - - - - - - - - - - - - - - - - - - - - This needs to be translated into language primitives - -- each variable-name resolves to a TensRep or an IndexedTensRep - -- the outer-product command has to handle any combination of number and - dimensionality of indices of its two inputs. - -- The identity TensRep must have the same number of indices, the same raised- - lowered, and the same dimensionality as the result of the outer product. - - - -- If the number of indices of A and B are known at translation time, then a command - can be generated and its name put into the syntax tree as the from-into pattern to use - - The plugin looks at the data-structures it is handed and checks compatibility (rules - about number of indices, raised vs lowered and so on). It then performs a generic - outer product code that has one loop. A vector of index values, plus the two limits - for each, is kept. The loop increments the lowest index each time through. When - that lowest reaches the upper limit, it increments the index above it, then resets the - lowest to its starting value. When the one above it reaches its upper limit, it - increments the index above that then resets to starting value, and so on, until the - highest index gets incremented to its limit (limit checked against is one larger than - the largest value want the index to take). This generic code works for any arbitrary - number of indices and dimensionality of the input TensReps. However, good luck - - efficient if they can state somewhere the range of number-of-indices the input - TensReps can have, or state the most-likely number-of-indices (generate commands - for the most likely values and save this generic as a catch-all.. at run-time a switch - on the sizes jumps to one of the generated commands or to the generic). - -- would be nice if the invariants form could be used somehow in the generic catch-all - Sequence of Programmer Editing - Code Take 2 - - -- The Model is the syntax graph. - -- The Visualizer reads the syntax graph and generates a DisplayList. - -- The Display paints the DisplayList, for a person to see - -- The Display also accepts GUI gestures such as mouse-clicks, keyboard strokes, mouse movements, icon clicks, etc. - -- The Display packages the GUI gestures together with relevant information and sends package to Modifier - -- The Modifier translates packaged GUI gestures into modification commands - -- The Modifier performs the modification commands, which change the syntax graph - -- The Modifier notifies the Visualizer of the changes made to the syntax graph - -- The Visualizer generates either a DisplayListUpdate or a new DisplayList and sends it to the Display - -] GUI gestures are used to construct a syntax tree - -] As the tree is constructed, it is visualized then displayed - -] The Display has a set of standard DisplayElements that it understands. DisplayElement is a standard data-struc that - the Visualizer and Display both understand. - --> A BaseDisplayList replaces everything that used to be on the Display's canvas. - --> A DiffDisplayList modifies whatever graph is already on the canvas. This allows the visualizer to only send diffs - when it updates. This is especially useful for just edit-point movements or sub-tree focus changes or selection changes - (edit-point is where the cursor is blinking.. also known as the insertion point.) - -] Upon receipt of a DisplayList, the Display updates its canvas and repaints it. Changes in focus, or movement of the - edit point, etc, show up this way. - -] GUI gestures are relative to the edit-point, the focused-on-sub-syntax-graph, and the selected syntax-sub-graph - -] The gestures are packaged and sent to the Modifier - -] The Modifier translates the gestures into modification-commands. - -] The edit-point, focused-on sub-syntax-graph, and selection-sub-syntax-graph are owned and changed by the Modifier. - The changes are sent to the Display via the Visualizer. - -] The Modifier modifies the syntax-graph, including adding new nodes, moving focus, moving edit point, and so on. - -] Modifier tells Visualizer the changes it made. It sends a list of nodes that have been modified, including those entering - focus and those leaving focus, and those that gained edit point and those that lost edit point. And those that entered - and left particular selection-collections. - -] Visualizer uses the list of modified nodes to decide if it is better to send a diff or a new base. If a diff, it uses the - modified list to construct the diffDisplayList. - -] When editPoint changes, the Visualizer determines the effects this has on valid GUI gestures, and sends the new valid - GUI gestures with each element in the diffDisplayList or baseDisplayList it sends to the Display. For example, when - - the kinds of gestures that are valid to perform on that point. The Visualizer code that the programmer creates as part of - creating custom syntax includes specification of how to determine the valid gestures for each link and node. - -] The programmer chooses among the valid options, or types the beginning of the option to have it filled in by the - Display, or whatever - -] the Display packages the gesture and sends it to the Modifier. - Repeat - GUIGesture to ModifierCmd - Translations for Tensor Notation - 1) To be filled in.. - external GUIs for coding tools - The srcHolder, workSheet, and programSheet all have visualizers and editors. The OSInstance, in fact, is a - specialization of workSheet and has a visualizer and Editor itself. Anything a person sees is generated by a - visualizer (there can be many variations of visualizer for the same thing, each displays in a slightly different way, - according to personal tastes) - Any modifications made by a user looking at a GUI are made by interacting with a tool that is an external processor. - This tool draws the visualization, accepts GUI gestures, packages them with their relationship to the drawn visual - elements, and sends them to the editor, which is inside the OSInstance, attached to whatever processor is being - visualized. - So, there's a visualization of the OSInstance, which appears as seen above.. this shows processors, namespaces, and - inclusions.. one can delve down into any processors that appear in the OSInstance that one's Authentication has the - Ability to see. - The OSInstance visualization is focused on seeing the existence of processors and the inside-vs-outside relationships - they have to each other. - However, a workSheet visualizer may instead want to hide the existence of processors. It may, instead, show the - equivalent of a MathCAD worksheet.. visualize src as being on a sheet of paper, feeding into a symbol that - represents a srcManipulator, with the src that srcManipulator was created from available in a different visualization.. - so, everything one sees is symbolic.. meanwhile, on the OSInstance Display, the srcHolder shows up instead of a - visualization of the source inside it, and the srcManipulator shows up as a processor that is placed by a creator, and it - shows the srcHolder that srcManipulator was created from as a processor. The OSInstance view might have a small - window on top of srcHolders that give a glimpse of what is inside as a visual aide for the viewer.. - The essential point here is that the person viewing can use either the OSInstance visualization or the worksheet - visualization to add new processors, change connections among processors, and so forth. Whatever is done in one - Display will show up in the other Displays.. - Property Patterns - A property is a pattern. Something that has a property is something that matches the pattern. The pattern is - - - be re-written using the property's from-into pattern. - For example, distributivity is a property. The from-into pattern is that anything that matches, it is known has - - - - - - - - - - - pattern. The integer pattern is a string containing digit characters. The pattern is a complex one because - number-base calculations have to be performed to determine if the value of the string is larger than what - matches the integer-pattern.. IE, in Java, it is, what, plus or minus 2 billion something or other.. - So, the from-into pattern is also complex.. commands have a format of what they accept. IE, in formal - definition of processor, the processor has an interface. The interface is defined by a number of patterns. - Anything that matches the interface patterns can be accepted by the processor, and will give the behavior - specified as the processor's behavior. - Remember the specification is what was used to make the processor.. but the specification is NOT the - processor. The processor is made from other processors, and so on.. Giving a processor something that - doesn't match its interface's patterns doesn't mean the processor won't do anything, it just means that the - deriving processor(s) won't show behavior that corresponds to a derivation of the Specification the derived - processor was made from. - So, the into for a Type is.. what? It is acceptance into all interfaces that use that type-property's pattern as - what they accept? - - as a scheduling constraint -- (seeing the opportunity to apply the from-into pattern attached to a property- - pattern as the opportunity == scheduling-constraint on scheduling the from-into command. Every re-write - is a command.. the application of a from-into is a step of computation.. the perform of a re-write is a - computation. - Well, there you go.. in both cases, match to property-pattern is used as a scheduling constraint. In the case - when the property has its own from-into pattern attached, then match to the property-pattern is the constraint - on scheduling the property from-into. In the case of some random command specified that the inputs have to - match the property-pattern, then match to the property-pattern is a scheduling constraint on scheduling the - random command. - Both cases are the same, both are match to property-pattern IS a scheduling constraint. The only difference is - that a command attached to a property-pattern is one that someone else has written, and is widely known. - Whereas a random command inside a program is a relatively recently written command, and is known only - to a few (only those who wrote the program).. The only difference is the USE by people.. that's it. It's just - a logistical difference that is a property that people calculate.. the property here is the pattern of when the - command was written down, by whom, and how widely known it is.. - Okay, so back to Types. They are property-patterns, like all other properties. The one thing is that there is a - higher-level property pattern at work. The set of property-patterns that match a logistical human-usage - pattern is the set of programming-language Types. The usage pattern is that the Type property-patterns are - used during specification creation. A specification includes defines of interfaces. So, in a procedure, for - example, one states the type that each parameter must match. myProcedure ( int A, float B ).. the int and - float are saying what patterns must be matched by the things communicated in to a processor made from the - myProcedure specification. - The specification is passed through a source manipulator that performs pattern matching. For every - communication specified to be POSSIBLE between processors, it checks that the communicated thing will - match the interface Type property-patterns. - By the way, in a specification, when one writes down the usage of a procedure inside another procedure, one is - stating that a communication is possible between two processors. One processor *would be* an instance - made from the calling procedure, the other would be a processor made from the called procedure. What's - important here is that the specification is not performing a communication. The specification is only saying - that, when this spec is used to create a processor, there will be two created processors in existence, and those - - invoked in many places.. this means that when a calling procedure specification is written, it is not known - what specification will be used to create the processor hooked up in the called-procedure position. - That's the key point, is that stating a called-procedure is only stating a communication interface. It is only - when processors have already been created and a communication takes place between the calling and called - procedure-derived-processors that it is known what the processors are, and what type-property-patterns have - to be satisfied to perform a valid scheduling inside the calling processor to the called processor. - So what this means for the syntax tree is that Type is a property-pattern. So, include general property-patterns - in the command syntax-nodes. Perhaps include a-priory known-to-satisfy property-of-properties sets. IE, - include a Type set of property-pattern assertions (defines). - Seeing something like a linked list of properties. -- should command-nodes have them? Yes.. many re-writes - are a-priori known to be valid for commands. Hmmm.. think some of those rules are for combinations of - commands.. let's see.. the distribution did above, it worked for times outside, with plus inside.. doesn't - work for times outside and.. ? Hmm, is it possible to create some kind of complex compound binary - operation for which such a distribution does not work? IE, if perform multiply first, then do the binary - operation, get a different result that doing the binary operation then multiplying the output. Well, YES, any - non-linear binary operation will give a different result if do the multiply to the inputs before doing the non- - linear binary vs doing the non-linear binary then multiplying the output. - So, that's the answer.. yes, only some combinations satisfy the from for a given from-into re-write. Means that - the property list has to be done in a way I have to think about a bit more.. In any case, the Type property I - can define to be universal, just need to attach to inputs to commands, and attach to results from commands, - and make constant be an output from a built-in command. And program-inputs be, inside the program, - outputs from an input-port command, or something.. they're just inputs to the program's top-level - commands.. maybe a stream of them.. - By the way, theorems are each exactly a property-pattern. They have a pattern for what satisfies the necessaries - - doing a proof, getting from one step to the next by invoking a theorem is doing two things. First, it is - asserting that the from-line matches the theorem's from-pattern. Second, it is stating the result of performing - the re-write. - Finding a proof is then the same as playing chess.. One performs a search, in the middle of the search, one is - - about finding all theorems and other re-write rules that have either a from or an into that a heuristic says - might get closer to a sub-goal in the search. The search then tries all kinds of sequences of performing re- - writes until it finds a sequence that goes from givens-patterns plus hypothesis-pattern to goal-pattern. - The thing people do that automated don't yet are two things: one, spontaneously recognize patterns about the - - - data is put through re-writes, and those re-write results are put through more, and so on, then recognise a - pattern among the output of rewrites that are several layers up. That's equivalent to the heuristics in pattern- - search, I believe.. yes, if patterns can spontaneously be recognized in the outputs of re-writes that are at any - arbitrary layer up, then patterns about patterns can be popped into existence. That is a key thing that must - be automated.. thinking perhaps have already accomplished this in statistics and machine learning stuff.. - could grab into this framework and see what an inorganic thing would come up with for heuristics in guiding - its searches for proofs. And see if it can use multiple conflicting goals and balance them.. goal of - maximizing aesthetic pattern-match.. process the search-path by putting it through partial-matcher to - aesthetic patterns. - Would need to include the aesthetic partial-pattern match output as part of optimization that is performing the - search. In real life, don't get perfect pattern matches when search for a sequence of re-write rules to apply.. - - - all that matched the start and some sequence got them to the end. They also did an optimization by - - - - - recording spotlight for most people, so it is a primitive, a result from a point-to processor. - - - - - - the final into, search for any valid second input that results in the given into. - Hunh, I wonder if instead of having some primitive operation in neurons, if instead just have something that - does a search, using the standard search thing, but below my recording device? When I invert a rule, am I - just invoking a standard good-old-fashioned search? - Crap.. battery gone.. this has been fun. - SrcPhrase instead of syntacticEntity? One concept is a collection of src-datums, the other is a collection with a - single syntactic meaning.. the syntax machinery handles a syntacticEntity as one thing.. - Syntax Graph Nodes - How is the syntax graph used? What should the nodes look like? - -- Have to be able to write code (like see to the left, when this was written) that says what node - - includes information about what GUI Gestures are allowed relative to the new syntax node.. - for example, adding a root of a compound syntactic entity enables GUI gestures for adding - the sub-portions of the compound syntactic entity. Those GUI gestures only become - possible to the person interacting after the root of the compound syntactic entity has been - added. - The Visualizer is responsible for telling the Display what GUI Gestures are allowed relative to - each GraphicalElement. (Maybe should change the name to Visual Element..) - So, on the long drive, seeing a few things: - -- have case with Tensor notation where have the column things.. those are not visual, and - they don't have any semantic meaning, they are purely mechanics of the grammar of the - syntax. - -- When do src manipulation, will have custom syntax, and a srcManipulator won't know what - - - when making transforms looking for ways to fit efficiently onto hardware with part - structure.. - -- Leaving re-writing till later.. only concentrate for now on something that enforces the - grammar, allows custom grammar for new custom syntax, and is visualizable with custom - visualization that turns the custom syntax into a standard GraphicalElement chain. - -- When add a custom vector graphic, will have boxes denoting inputs placed at particular - locations.. want those locations to be defined as part of defining the custom syntax.. the - box locations are known by the visualizer but not by the Display.. the visualizer creates box - GraphicalELements are the appropriate locations relative to where it places the custom - vector graphic, and it sizes all appropriately. Thus, the visualizer receives code as part of - the custom syntax definition that gives the visualizer the info it needs to place the boxes in - the appropriate locations.. and then to put other symbols in those locations once the boxes - get filled in via GUI gestures. - -- The syntax graph nodes are only used for getting the grammar correct while building the - graph.. so the editor receives info in the custom syntax specification that tells it what - syntax-graph-element to place at the insertion point in response to a particular GUI gesture. - The editor relies on the Display to have obeyed the directives given to the Display by the - visualizer.. these directives cause the Display to only allow grammatically correct GUI - gestures to be made by the person. - -- The Visualizer receives information as part of the custom syntax spec that it sends along to - the Display. This information is attached to each GraphicalElement and embodies the - grammar of the syntax. The information tells the Display what GUI gestures are allowed in - relation to each graphical element the Visualizer sends to the Display. - - These GUI gestures may be drop-down menu entries, or right-mouse menu entries, or - valid keyboard strokes.. each menu entry is present only when that GUI gesture is allowed. - From many GUI gestures, they are only allowed when a particular node is focused on. So, - the mouse-menu and valid keyboard strokes change as the focused-on GraphicalElement - changes. - -- It is expected that many different types of Display will be written.. each will handle focus, - and Display-relative commands like zoom and pan and probably font (but have to wait and - see if practical).. and thinking some kind of intermediate thing specifies the GUI gestures - that are valid.. then one Display can indicate the valid gestures as drop-down while a - different one indicates them by icons on a pallette or something.. - -- It is expected that many different types of Visualizer will be created. It might be best to - determine font in the visualizer rather than in the Display.. Font is important.. different - fonts will have different semantic meaning.. for example, with Tensor notation, which has - abstract indexes.. those indexes are characters.. the characters represent something that has - meaning only in that they get matched with other such characters.. meanwhile something - needs to represent free-choice inputs to a syntactic entity.. - - for example, may want to define something that has two free inputs on the left side, and - has two holes on the right side where there are input boxes of a syntactic entity that have - not been filled in. Need some way to indicate which of the left-side inputs should be - shuttled over to which of the right-side holes. Can do this with arrows, but want to be able - to do it with variables also.. so, have a special font to use for this purpose.. thinking an - italic font.. so then in the case of Tensor notation, have on the right hand side a Tensor - entity that has 6 index columns, with 4 of them filled in with letters.. well, those letters are - literal for the FIRST re-write that takes place.. the two empty columns require that the left- - hand side have a letter that matches to a same letter on the right-hand side in one of the - empty columns. This is why different fonts are needed with different semantic meaning. - -- Will have multiple Visualizers in each processor that can be visualized. Note that only - Holders and Spaces can be visualized.. processors that are performing number crunching - it's not clear.. it is expected that they get significantly rearranged for the purpose of - specialization.. which says one can't see in to them because it will be a hardware-specific - thing that is who knows what.. at the same time, one wishes to debug, so one wants a - verbatim view of processors corresponding to the original source-specified processors, and - one wants a view of datums moving among these processors. - - Thinking perhaps have some kind of debugging option that does a non-optimized - specialization that allows each processor-shape specified in the source code to be see-able - in a visualization of a processor created from that source. And, to be able to tag datums - flowing among those processors and get some kind of visualization of the interleaving of - data flows and whatnot, for seeing unexpected need for atomicities and so forth.. - -- Seeing maybe some kind of unique ID given to each syntactic entity.. there will be many - Visualizers for a given srcHolder, for example.. have to be able to match up something.. - what was I thinking about while driving? - -- This syntax is not interpreted form.. - -- Seeing syntactic sub-entities like the Tensor index columns being used in ways like letting a - variable stand for either a raised or lowered abstract index, which gets picked off from - somewhere else and landed in there. - -- One biggie is re-use.. the thing about being able - -- Seeing have a symbol stand for an entire worksheet.. for example, construct this worksheet - that has multiple processors on it, some srcManipulators, and creator spitting out a - processor created from the manipulated source, and so forth.. that whole thing has some - input ports and some output ports. A custom symbol is created, and the inputs on the - symbol attached to the inputs on the worksheet, the outputs on the symbol attached to - outputs on the worksheet.. then that symbol can be placed on some other worksheet.. - - Let's see.. can such a symbol be placed directly into EQNLang source? Question here is - whether have different kinds of source for doing things in workSpaces than have for - - from-into substitution on and get SOURCE CODE as the into.. now, talking about getting - actual, already created and running processors as the into.. the first is a manipulation of - data inside a srcHolder, the second is modifying the namespace of a workSheet and - invoking OS commands to translate, create, and place.. - - So, have one unified language where all that is mix and match, or make a separate - architectural language? - - Has implications for the syntax graph, and how re-write happens, and so forth - -- The syntax graph is going to be close to the surface.. it's close to the visual elements, and - not yet in the form that would make sense for executing.. it's a raw form that is expressly - for entering correct grammar and visualizing it.. - - Worry about semantics of the syntax later.. when do, will probably end up modifying the - syntax approach quite a bit, but for now, just concentrate on getting the syntax entered, and - entered in a way that have the flexibility to define matchable and substitutable patterns.. - -- Want the := definitions to have a simple mapping to from-intos.. want to be able to enter - from-intos directly.. worry about making them pretty later.. for now, just make entering - from-intos display straight lines, maybe in a grayed or a light color or something, between - the from-location and the into-location. - -- Starting to see this.. have things that specify the node, call it node Foo, that corresponds to - a custom-notation.. have things that specify the grammar for what other nodes can be - added in which parts of the Foo node (children, parent if have special non-symmetric parent - reqts).. have things that specify the GUI gestures to indicate adding a Foo node.. have - things that say how to break a Foo node into a GraphicalElement representation of it. - -- Have a tool that can grab a vector graphic into, then drag boxes to locations around that - graphic. If a compound syntactic entity is what are building in the tool, then define the sub- - components and state the grammar for which sub-components can go where. The sub- - components are also built in the same tool. - -- the tool will generate a from pattern, to which one assembles an into pattern and connects - parts of the from to parts of the into. This tool will spit out all the things needed to give to - the Visualizer, the Modifier, the Display, and the re-writer (The Modifier == Editor before) - the Modifier gets the piece that constructs an actual syntax-node(s) in response to a GUI - gesture.. so that's where the actual syntax node that goes into the Model is defined. The - Model is passive so it doesn't get anything generated by this tool. The re-writer gets a - separate syntax-tree of the from-into pattern.. - -- Thinking the from-into patterns have to be visible in the srcHolders as well.. not sure what - want visualization to be.. when browsing, will be at some level of the code, and want to see - the from-into for a particular symbol.. - Short list of what want the syntax graph to do (not even sure it's going to - be a graph, or a tree..) - -- Syntactic entities ==> a processor is a syntactic entity - -- Kinds of syntactic things: - -- -- Variable: - - - - pattern - - same as #include <came back and added this after the below - discussion> - -- -- -- ?Other kinds? The first kind is a semantic variable.. it has - computational meaning, is used during searches for re-writes the - second kind has only internal-to-syntax meaning.. it's just a different - form of expressing an arrow.. such variables are never affected during - re-write.. they don't take place in the search for re-writes and have no - bearing on which things get re-written.. they are only used during the - mechanics of performing the re-write after a re-write has been chosen.. - the second kind of variable has different rules for how it is used.. - - What other kinds might there be? Perhaps ones that are simple - - are distinguished by - which - processor (which animator) recognizes the - - variable is recognized by the re-write scheduler. The second kind is - recognized by the processor that gets scheduled to perform the re-write - operation. A third kind may be a variable that is recognized by the - srcHolder as something that is outside the system of re-writes. Maybe - even variables that the Modifier and Visualizer recognize that - everything else treats as verbatim. - - Okay, so a concept here of one kind of variable for each kind of - processor that touches the source code. There is one kind of semantic - for each kind of processor that touches the source code.. that - processor touching the source code is the animator for that semantic. - So, how about a further kind of variable that represents a processor, - like a memory processor, like a storage location.. such variables - would have some re-write semantic (affect scheduling of re-writes for - example).. such variables would also have an execution-model - semantic for the primitives execution-model. This would translate - directly to a hardware-processor interface semantic (ISA semantic), - such as a main-memory location. - -- -- -- So, leave room in the syntax for additional kinds of variable - -- -- -- So, a variable in the syntax is a character string, with a variable - type, and that variable type has a font assigned to it inside the - visualizer - -- -- A from-into pattern is a syntactic thing.. but it's a different kind.. - it's communicating something to the re-write processor that the re- - write processor uses to find matches.. A from-into pattern is NOT - part of a processor-specification, but rather defines semantics for - patterns that might appear in a processor-specification. A from-into - pattern does not state the use of processors, rather it specifies the - behavior of processors that might be used. It specifies what - processors invoked elsewhere do. IE, a from-into is like a procedure - - a procedure. - - patterns.. - - - Two different things.. - - - - communication between processors <placing syntactic-entity in in-box - postion of another syntactic-entity>, have specification of a from-into - - - syntax-graph and is indicated by a property attached to the syntax- - node. The property states which kind of assignment. May have other - kinds of assignment that indicate semantics of additional kinds of - variables relative to which of the kinds of semantic the variable is - recognized by. IE, each kind of processor has its correlated kind of - semantic that that processor is the animator for. Each of those has its - own kind of assignment. That kind of assignment states the behavior - of the variable when the variable is recognized by the kind of animator - that recognizes it. The different kinds of variable are kept separate by - having a property attached to the variable node that says which kind - of variable that node is. The grammar enforcement parts will ensure - that a variable of a certain property only shows up in the syntax graph - in places that it is grammatically allowed. - -- -- Q: how to make sure that have enough flexibility in the - - - In use, what kind of customness is wanted? Want to be able to - specify processors that operate on source code as data.. if wanted to - be more pure, would allow easy inter-mix of processing source as data - then using the processed source to create processors that behave - according to the processed data.. which in turn can dynamically - decide if they want to manipulate source further, then that - manipulated source turned into a processor, and so on.. But, in - practice, turns out don't really use that ability very often.. may be - cool, but the practical implications in implementation and speed of - processing have more impact on the usefulness of the language than - the presence of that ability has. - - In practice, as far as I can tell so far, all the cases where perform src - manipulation, it's acceptable to take the time to do a translation step - after the manipulation, to translate the manipulated source into some - native format for the hardware. Then create the processor that - behaves according to the manipulated source from the translated-to- - native form of the source. - - Just need some nice syntax to indicate this.. in Lambda, had a - deceptively simple syntax.. deceptive because it looked the same as - every other kind of code.. but in practice, there is a great difference - between places in code where code is actually dynamically modified - then the modified form used to create a processor vs places in code - - - looks like a src manipulation, but in practice, it is only ever used as a - static re-write.. Must have call-by-name to actually perform src - manipulation that then gets turned into a processor. And OCaml - doesn't have it.. that's part of the evidence that such a feature in the - language is rarely used in practice.. so EQNLang does actually have - the equivalent of call-by-name's dynamic code-modification.. but it - requires performing a translation step on the modified code, and it - - - the same form and one must recognize the implications of the use in a - call-by-name language.. in contrast this feature has an explicitly - different form in EQNLang.. in fact, EQNLang can perform OS calls, - so the dynamically-modified source could even cause the modification - of the workSpace to cause a brand-new translate-create step to be - dynamically inserted.. the dynamic insertion of the translate-create is - performed by a processor whose source was itself dynamically - modified.. so there is full theoretical flexibility here.. only a loss of - - attack on the missingness of the call-by-name sneaky use will come.. - Mainly Haskell camp, I believe. - Short list of what want the syntax graph to do (not even sure it's going to - be a graph, or a tree..) - -- Syntactic entities ==> a processor is a syntactic entity - -- Kinds of syntactic things: - -- -- Variable: - - - - pattern - -- -- -- Leave room for variables that are defined with meaning for other - animators than those two.. - -- -- Property.. list of them attached to every syntactic node.. each - property has a property-of-properties property itself.. for example, a - - - - - - - By having flexible properties like this.. for each property, include the - - - used to re-write things that match the property.. or, actually, state - which from-into patterns are at least partially satisfied by a thing that - has the property.. that makes a general system for deriving properties.. - and the equivalent of type-checking will be property derivation, and - search among the intos of all the froms that satisfy for the into that has - the properties required by a position in the syntax-graph. - - The property checking system might be turn-offable when performing - a translation of manipulated source in a live system where a person is - waiting for the translation to complete.. rather, include facilities to - back-track from a problem that occurs due to incorrect properties.. - back-track back to the source manipulator(s) that code came out of that - caused the property mis-match.. - - This would imply that src manipulation must perform searches itself.. - for example, cause src manipulators to perform re-writes themselves, - instead of having the normal translator do it? Something like that.. - will have to see performance issues and whatnot when it gets used.. - - What really want is for all this machinery of re-write animator, of - thing that processes properties-sets, of existence of syntax-graph, to all - be specifiable from within the language itself.. want the language to be - able to create itself within itself, and extend itself, and re-shape it's - nature, from itself without defining an entirely new system, but rather - modifying the one the modifications are stated in terms of. - - IE, want to be able to state modifications of the terms-of processor the - modifications are stated in terms of. - - Maybe that will be my next language.. these are much higher than the - basic processor definition, or a Turing machine, or a lambda.. what - want is a higher language that has nice facilities for people and good - search primitives that can specify modifications of itself in terms of - itself. To the point that the language is completely modifyable in every - aspect, and the higher facilities like property-checking to derive which - into fits the interfaces, or facilities to state the existence of such - facilities as themselves are modifiable using facilities that have already - been defined.. - - You know, thinking will need several levels to do this.. such - modification will require modifications on multiple levels.. for - example, start with an implementation of the basic processor definition.. - then use that processor definition to specify higher facilities like - explicitly linking name-spaces and searching them and whatnot.. - - Lost it here.. too far out in na-na land.. - Short list of what want the syntax graph to do (not even sure it's going to be - a graph, or a tree..) - Kinds of syntactic things: - -- Variable: - - - - -- -- Leave room for variables that are defined with meaning for other - animators than those two.. - -- Property.. list of them attached to every syntactic node.. each property - has a property-of-properties property itself.. - - Have a src manipulator defined that takes a syntax-graph and uses - the properties to derive what properties have to be added to each node in - order for them all to be consistent. After that, the re-write src - manipulator can be turned loose.. when this src manipulator has several - - that has properties that match the needed properties. If none exist, it will - try to generate a from-into that has an into that satisfies the properties - needed.. requires that generators are reachable from the programSpace - that are capable of generating such from-into pattern. - - At first, thinking programmer makes all properties explicit.. or, - maybe the srcManipulator responsible for deriving them all simply - presents choices to the programmer and makes them pick.. the human - does the NP-complete part. - -- entity-root.. this kind of node is a processor. - -- -- consumable - - - the replacement part.. the entity is consumed and in its place appears a - re-written form or a datum.. whatever it gets replaced with is the input - to the parent of the consumable entity-root. - - A consumable entity-root has children-spots, each of which has - properties attached that indicate the properties a node that goes in that - child position must have (IE, the properties attached to a child-link state - the properties that the consumable-entity-root that gets linked-to must - replace itself with).. this is equivalent to contracts, I believe, in some - sense at least, don't really know what contracts are formally.. but idea - here is that the link says what input requires and the linked-to root says - what output is generated and those have to match up, according to - property-matching rules.. have a property-system, which is a src - manipulator, that enforces this. The property-system might also be part - - - An entity-root can be either derived or primitive. If primitive it states - the properties of what it replaces itself with. If derived (custom? what - - - syntactic-entity. (In this case, the property-system will have to interact - with the re-writer, which is actually performing computation.. re-writes - are semantic computation steps). - -- -- persistent-across-inputs. - - An entity-root can alternatively represent a processor that persists - across inputs. A src manipulator would be an entity-root like this. Such - syntactic-entities may have both input-links and output-links. The two - kinds of links would be visualized differently, and would have different - grammar. An output-link could then be connected to the input-link of - some other persistent-entity-root.. - -- -- Notice that a persistent-across-inputs entity-root can only be - connected to the ports of the same kind of entity-root. - - - - input port of a persistent connects to an input-link of a consumable.. at - - output-port. - - Visualize it thusly.. the persistent entities are there across inputs.. - an input comes along, from outside the OSInstance or from another - persistent.. that input passes through the port to the inside of the - persistent entity, and goes into the input of a consumable.. a chain- - reaction of consumptions occurs, ending in the final consumable turning - into a datum that hits the inside of an output-port. That causes the - datum to pass through and travel between persistents. - - - math is thought of as only being consumables.. whereas imperative has - the notion of persistent -- the persistent storage location (which is a - memory processor). - - Can unify the two by introducing co-recursive thing that continually - re-writes back-and-forth.. that's a storage location.. so each - consumption causes the creation of another consumable, and that in turn - causes the creation of another, and so forth, back and forth.. That same - technique can be used to re-create a consumable that waits for inputs.. - provide some do-nothing input from the co-recursive twin. But make it - so that any input to the input-port will pre-empt the do-nothing input - from the co. Could even make receiving an input keep that input around - until it gets a pair, when multiple inputs are needed as a set.. or, to be - analog of physics, would need to do something a bit more exotic to get - the schedulings to all be consistent with observation. - -- entity sub-node - -- -- The index-column in Tensor notation is an entity sub-node.. such sub- - nodes have properties attached, just like everything else. - - - right-hand-side. So, question: is syntactic-entity one-to-one with the - - Oh boy.. well, how about when have an expression involving many things, - - - Okay, whatever the answer, think at point of being able to start making - some definite stakes in the ground of defining syntax-graph node.. - What a syntax-graph node is is a collection of properties.. the only thing is - - is... drumroll.. a property. There is a processor in the system that - expects that property-type to always be present, so instead of putting it - into a linked list, give a fixed position to this property-type. The - processors that care about this property-type are: grammar thing in the - Display, the visualizer, and the Modifier.. plus the re-writer. - So, syntax-graph node-type, with type-specific sub-types - If an entity-root, then need either primitive or custom (derived?), and need - name of entity - Each entity-name may have other properties required: - Each entity-name has a specific number of children inputs (when these - input-links are null, they are visualized as boxes) - each child-input has property-list that must be matched by whatever goes - there - Each entity-root has property-list of properties of what it replaces itself with - (?can be filled in during re-write? Progr interaction issue, I guess) - -- thinking the properties checking system not needed.. because the - grammar doesn't allow the construction of a syntax graph that would - violate.. Q: is such a construction-based approach too limited? - How about, first crack at EQNLang has no properties system.. it relies only - on the construction-grammar to ensure input-required matches output- - produced properties.. - So, have a link in every syntax-graph node that is the head of a linked-list - of properties.. even if don't use them for the equivalent of type- - checking, want the stub for them there.. will use them probably on - custom syntax nodes, pass them along to the Display maybe, then the - Modifier.. will probably find lots of uses.. - - - - - - - - - - Syntax-graph node - propertiesListHead - nodeType - - entityRoot - entitySubNode - entityLeaf - reWritableVar - entityRoot is either consumable or - persistent - - propertyListElem - <fieldName | type of thing goes in> - <fieldName | valid values> - consumable entityRoot is either re- - writable or primitive - consumable, re-writable entityRoot - is re-written by something that - resolves eventually to something that - - property-set that matches one of the - list of type-set properties allowed by - the input-link the entityRoot is a - child of.. IE type of entityRoot must - resolve to a type accepted by input- - link - You know, the issue with data-structures vis a vis dynamicness is that select- - from-property-set is expected to be there for particular sets in relation to - the presence of choices from other sets. - - - - an a-priori statement of such requirements. Thus, some data-strucs are a - statement of the set of choices-from-property-sets that must appear - - myStruc1 is the name of the set of choices-from-property-sets. type1 is - the name of the set that a choice will be pulled from. Var1 is the name of - the choice from the type1 set, Var2 is the name of the choice from the - type2 set. The statement of the data struc itself is a pattern that states that - a type1 choice and a type2 choice that are correlated are present. The - name of the pattern is myStruc1. - When a lot of strucs are defined, then when create a variable, and state that - - The property is that the contents of the variable matches the myStruc1 - pattern. The set of different strucs is a set of properties. This set never - appears explicitly in a language, but it does appear in a compiler or - interpreter for the language. This set is the set of all such patterns that - have been defined. Each of these patterns has the data-struc property. - - s - - patterns in the data-struc set has the data-struc property. Each of these - patterns with the data-struc property correlates (I guess pattern == - consistent correlation) a number of choices. Each choice is from a - particular other set. The pattern of sets the choices are made from is the - data-struc pattern. The values chosen are the values of a particular datum. - - can be invoked to get that two choices exist in the datum, and that one - choice is from the type1 set, and the other choice is from the type2 set. - How this is all useful is that this whole thing can be made meta. One issue - I've been having with defining the Java data structures is that the elements - of the structure change depending upon the values placed in certain fields. - This dynamic-ness can be gotten around during this a-priori design of the - - - But, what happens when customize? If want to allow customization to the - point that new sets of properties or even new sets of sets of property- - patterns, etc are allowed to be added to the language, then such a-priori - definition of data-strucs is inconsistent.. don't see a way to allow such - customization when using a-priori defined data-strucs. - So, make the properties system dynamic.. instead of relying on positions in a - data-struc, and defining the data-struc a-priori, make a more primitive - thing that takes the pattern that defines a property, and that also takes a - thing that says what to do with that property.. essentially, making more - and more of what the compiler does be now after-the-fact customizable.. - like plug-ins to the compiler, in a way. Making more of the compiler - meta, in a way.. what is hard-coded in the compiler, am instead taking the - patterns underlying that hard-coding and instead hard-coding the - underlying patterns.. then making a spec that is animated by the new - more primitive hard-coded.. that spec has derived behavior that matches - the used-to-be-hard-coded. So, a much smaller set of behavior is hard- - coded now, and more of the behavior is stated in terms of primitives that - can be used in the language itself being compiled. - That would be fun for a future version of the language.. - For now, think will stick with just including simple custom properties and - their associated patterns.. will put the potential for them into the syntax- - graph node data-struc pattern.. but won't really use that potential until - much later, after have more hands-on, and more structure defined.. - a ResolvesTo field.. later, will allow - this to remain empty when first add a - node, and will have a system - invoked by the Modifier, and by the - Translator, that deduces what - properties many of the nodes MUST - resolve to.. will ask programmer for - help when get stuck. - nodeType is to indicate what fields will be in this particular version of a - syntax-graph Node.. see discussion of properties.. - syntaxDataType is the type of syntactic-entity.. this is customizable.. this is - used to match to type-of-link-to-is-acceptable.. in some node-types, have - links to other nodes, and a list of acceptable syntaxDataTypes that can be - linked-to - TokenType is what kind of thing can be used to represent the node.. in this - case, either a variable of type TensRep, or an input-box filled by some - expression that resolves to a TensRep - -- note, this is from way back, wasn't thought-out from implications point of - - of view.. so it's a bit inconsistent as far as implementing a type-deduction - system and a consistent grammar.. the properties are fudged together here.. - has to be re-done according to what worked out below. - Want a type that says what shape the syntax-node has - Want properties that describe the resolves-to of nodes that resolve - (in other places, want to know what properties must be possessed by a node - before it can be placed at the end of a particular link) - Short example of an editing - session: - -] The person does the GUI gesture to add a new outer-product node. - - position to add it (which the translator figures out by knowing where the insertion point is, or - where the mouse is when the GUI gesture is made) - --> This causes the node representing the command to be added to the syntax graph. The node's - child-links are empty. The Modifier moves the insertion point to the first child. - --> The Visualizer generates an update to the DisplayList. The update includes changing which link - is the focus pt - --> The Display paints the updated DisplayList - -] The user sees the command-symbol appear where the insertion point was and sees empty boxes - where each child is, with the box that is the first child blinking to indicate it has the insertion - point. - -] While the insertion point is blinking, the user starts typing a string. When done, they hit enter and - the string is sent as a GUI gesture. - - - - with an escape sequence or else use a mouse or menu gesture. For example, they could enter a - memProcessor variable, or a TensAbsIndex var, etc - --> The Modifier performs the command and adds a syntacticName node, with the string as the - name, and moves the insertion point to the next child-link - --> The Visualizer generates and update - --> The Display paints the new DisplayList - -] The person sees the string they typed appear as a syntactic-name node where the insertion point - used to be and they see the new insertion point blinking - - verbatim typed in by person using GUI - - - paints DisplayLists. One will navigate within the Display and it may at times be visualizing one - of the workSpaces or zoomed in on some other sub-set of the CTOSInstance. - Thinking that perhaps have only one kind of Display that morphs itself as navigate.. The difference - will be the GUI Gestures available.. for example, the pallette (toolbar) might change, the - mouse-menus and other menus might change.. they might even change as the focus moves from - one processor to another.. will have some kinds of command for workSpace, other kinds for - custom-defined Space, others for myDataHolder.. - So.. seeing have only one kind of Display on the local machine, which then changes itself into - specializations depending upon which processor in the CTOS Instance has the focus-token. - Thinking that even when zoomed in and only looking at some deeply embedded processor, can - still have the focus-token attached to an outer processor, and so the Display has the behavior- - specialization for that outer processor - Okay, so need the term Display, check. And need some way of saying what the Display behavior - has been specialized to.. so, how about EQNLangSrcHolder Specialization, or - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How one works with Syntax - What things will one do that the syntax tree must support? - -- have the whole properties thing down.. properties are soft, define new sets of property sets and sets of those and so - forth in customization code that is written when defining a new language. - -- For EQNLang, have visual elements in the syntax graph.. a syntactic entity has an element for each logical element in - the notation.. for example, when have pictures as the code, like the ones Gabe was drawing, the orientation in 3 - dimensions has syntactic presence because it has semantic meaning, the orientation conveys pattern-information used - - rotation, the length of the arrow, maybe the thickness.. each visual cue is associated to a semantic infum. So, each - visual cue has to have a corresponding syntactum in the arrow-syntactic-entity. - So, put a stake in the ground: each visually information-carrying aspect has a corresponding syntactic node that is part of - - Okay, getting close to capturing all the weirdness things..? Have italicization of some strings.. that's a visual cue.. the - meaning correlated to that visual cue is kept in a syntactum. In this case, thinking the syntactum is a property node.. - so, distinguishing a literal-relative-to-first-re-write name from a match-to-indicate-arrow-between-boxes-in-from-into - name is done via a property node. So, such names will both be self-contained syntactic-units.. They will have a string - with the visual shape of the name, and properties indicating, locally to the language, that one is a literal-in-pattern - variable, the other is a use-to-match variable. - So now, question coming, what distinguishes larger semantic roles, like role within re-write? IE, a variable is a match - candidate, while a command implies a particular syntactic-unit shape, and implies a particular from-into pattern.. very - different roles within re-write.. so, going to use just property-nodes, and have the language custom-stuff be the one to - figure out that those are very different things? - Yes.. why not. All have in syntax is one node correlated to each visual semantic meaning cue, and syntax-unit that - groups a single semantic unit. Have property nodes, which are what distinguish the role within the language, and what - determine the GUI rules of construction. And have structure nodes, which are what group syntactums together into a - syntactic unit. - And that, I think, is about it.. I think that's all that is needed. - Okay, so just two kinds of syntax data-structure.. structural nodes and property nodes. Every structural node has a - linked list of property nodes.. or maybe a hash or something.. linked list for now.. - Have two kinds of links.. semantic communication links, and structure-within-unit links. - So, in a data-flow language like math, have links that represent the flow of data. In a step-based language, have links that - represent transfer of animator between syntactic units (a semi-colon terminated Java statement would be one level of - syntactic unit, within that might have a procedure-call syntactic unit and an assignment syntactic unit.. the operator - precedence states the order of the animator traversing the links between syntactic units). - In something like CaD, what would be the analog of the data-flow link and the animator-movement link? Don't - remember it well enough at the moment.. - For CodeTime, say BaCTiL, have circuit-elements, have container-shape-definitions, have function-contents.. - What is Syntax - (and what is Semantics) - Finally, feel like getting close to closure on the whole syntax question: Here's the deal: When a human looks at a page of - math, there are two things: shapes and spacial position. Each has a SEMANTIC meaning. The particular shape - correlates to a pattern or some element of a pattern. The spatial position correlates to relationship within a pattern.. it - indicates which portion of a pattern the shape-correlated belongs to.(it's all patterns..) - So, syntax stands between visual on one side and semantic on the other. So, each visual cue that has semantic meaning - must have a correlated syntactic element. - The visual cues are shape features and spatial relationship. - For shape features, look at the difference between a C and a G.. there is just the one little tick at the end. In Chinese, I - believe, such little ticks don't merely separate two shapes, rather their presence or absence carries separate semantic - meaning.. don't know the languages, but such a tick could, for example, indicate singular vs plural, or differentiate - verb-meaning from noun-meaning, etc.. so particular shape matters. - - - sound (or more precisely mouth shape, as the sound is really a large family of similar sounds, it is the mouth - movement that is consistent) - - - - - (state change in the fundamental sense that an observation IS a state change).. so semantic meaning to a human is the - - - semantic meaning is.. a pattern, each part of which correlates to part of a human-action pattern. A human animating - the semantic pattern performs a correlated action-pattern, where each part of the action-pattern correlates to a - corresponding part of the semantic-pattern. - Okay, so semantics are patterns.. and human actions have pattern to them.. right.. correlation.. sweet.. finally, - - momentary flashes of seeing understanding absolutely everything.. all the patterns in all the world fit together, and - pattern is what All is. and seeing that is a pattern that fits all the patterns.. self-recursive.. and that sweet, tight, - - - several syntactic components.. the spatial position relative to each other indicates that the shapes belong to the same - - - - - - - - - both semantic patterns. - More on What is Syntax - Summarizing: - Visual pattern correlates to action pattern. The syntax pattern is a middle step between the two. The syntax pattern has a - feature for each visual feature that affects the action pattern (when action pattern is animated). - The syntax states exactly the visual pattern. The same visual pattern can correlate to very different action patterns for - - same visual pattern in EQNLang (consider the variable properties.. int's in Pascal, but could be Tensors in EQNLang) - The semantics states exactly the action pattern that the visual pattern is correlated to. Each language correlates a given - visual pattern to different action patterns. Semantics is to action-pattern as syntax is to visual-pattern. - So, the purpose of syntax is visual. The requirement of syntax is have a feature for every visual feature that can correlate - to an action pattern feature. - And that, in a nutshell, is syntax. - So, can have a single universal set of syntax patterns that is capable of capturing every feature of correlation in a visual - pattern. - That, then is the task to accomplish. - God this is great, after all that fear, and a couple weeks ago coming back to this, feeling completely inadequate and - incapable, it feels great to finally have this nailed. To have a set of underlying patterns that are consistent with - absolutely everything. Sweet. A small, simple set of patterns that fit with All. I love it. (something about that.. - finding a small set of simple patterns that fit everything, that are CONSISTENT with everything.. something about - that triggers this profound pleasure center for me.. recognizing when I have such a set of patterns underlying details - I've been wading through.. that recognition triggers a pleasure pump in my brain.. THAT is a part of why I do this - work.. and it's interesting that it's there.. have a feeling that many people don't have that trigger.. and those people - won't choose to pursue finding such sets of patterns either.. Interesting from the standpoint of Inorganic Life.. what - - - move IL higher in the goal-measurement.. but not really clear on that goal pattern yet.. it scares me a bit looking - - component).. yeah, and a name.. that seems to be lurking within me.. being the Archimedes of these times to the - future.. I feel like that's a built-in emotional mechanism thing.. (also interesting in itself to IL) ) - Back to visual elements.. the visual elements-of-correlation: - -- shapes - -- pieces belonging to a single pattern - -- multiple levels of patterns (full pattern being element of another pattern.. strictly visually) - -- can have a shape be a piece of one pattern - -- can have a pattern that has a given shape as part of it in turn be itself a piece of another pattern - -- can have a single shape in single spot be a piece of multiple patterns (namespace pattern as well as command pattern) - -- visual position of shape indicates: - -- -- inclusion as piece of pattern (ie, this shape is in this pattern over here instead of that pattern over there) - -- -- position within hierarchy of patterns, via inclusion directly within one particular pattern that is itself in the hierarchy - -- -- visual position can indicate a single shape's direct inclusion in more than one pattern at the same time - For example, consider a page of math. At the top a variable is defined. Down below a variable of the same name is used. - The use of the variable in that position places the variable both in a namespace pattern, which is how the semantic - meaning of the variable is determined, and at the same time places the variable in the usage pattern. The syntax should - capture the inclusion of the use in both of those patterns. One way is to have the syntax map the positions of each - shape relative to the other shapes. The other way is to use implications from the semantics of the language to - determine any links such as the namespace link. Looks like going to do this option.. use the - GUIToCommandTranslator to figure out all the different syntactic patterns to associate a given syntacticElement to. - So, in the syntax data structure, make a link be the embodiment of visual inclusion. Make a link to each pattern-root that - includes a particular syntactic element as a direct member of the pattern. A link is the equivalent of visual inclusion. - Let's see.. want an inclusion link for entire sub-pattern, so that's a link from the syntacticPatternRoot? Want an inclusion - link from each and every shape-containing syntactic element? - Seeing kinds of things that work across languages.. - -- have node that has a shape directly in it.. - -- have a node that is only a carrier and organizing point for other nodes (TensorIndexColumn for example).. - -- have a node that is the root of a single pattern.. - -- have a node that represents interaction between patterns? IE, transfer of animator in a sequential language, or transfer - of data in a data-flow language (like math notation).. must include this.. some languages have visual elements that - directly correspond to interaction (like BaCTiL for example, and other large grain data flow languages). Some - languages use physical location on page to represent this interaction, other languages have explicit visual shapes that - indicate this interaction. So, make it an interaction syntactic element, without implying the nature of that interaction.. - for example, consider Linda or Vitria, which would represent channels with syntax, and have syntax that indicates - interaction with such a channel.. in this case the interaction is posting a match pattern and accepting a match back, or - sending a message.. so could have a visual representation of send a message, which is an interaction, so make an - interaction an explicit syntactic element type. Or, want to play it safe and just make interaction be indicated as a - property.. so use a standard syntactic element as the link between patterns, and indicate that it is a link as a property - - more-work method (everything is a syntactic element), or have a little bit of built-in specialization (multiple Java types - of syntactic element) - Okay, quicker if I just start with a single Java type: syntacticElement.. then make links be a property-value, and make - interaction be a property-value, and so forth.. - - receiving-port or syntacticPatternRoot syntaxElements, where receivingPort and sytacticPatternRoot are themselves - properties attached to the target syntactic elements. - The properties will be handled by big switch statements.. can even make the propertyNames enums, one enum set for - each language. - So, here we go.. - Syntax Graph for a Simple Case - Have two kinds of structural syntax nodes: elements and links - Each kind of structural node has a list of properties attached. - The elements have a list of links, in addition to the list of properties - The links have a pointer to an element plus a pointer to more links in the list, in addition to a list of properties - A property node has a property name, a value from that property set, and a pointer to more properties - Red round-cornered boxes are elements, blue round-cornered boxes are links, green rounded boxes are property nodes, - and arrows are pointers among nodes - In practice, it turns out to be more convenient to inter-mix a bit of semantic information with the syntax information. - The structure of the graph remains essentially entirely syntactic, but some of the properties added have a mixed - semantic and syntactic role. For example, type information is partly syntax when used to choose the visual shape, and - partly semantic. Type properties are included in the syntaxGraph, in part, because they are used in the grammar. The - grammar is implemented cooperatively by the Visualizer, Modifier and Display, which all work together to only allow - building a syntax graph that is consistent with all grammar constraints. - In additions, the syntax information is a bit removed from a strict visual correlation.. the Visualizer acts as a translator - between the syntaxGraph and the pure syntax (which is one-to-one with visual). The syntaxGraph is thus a bit closer - to semantics. - For example, the syntax-graph states that an element is a command, and states the name of the command. But it is the - Visualizer that determines which shape will be used to draw that command. So shape information does not appear in - the syntax graph, only in the DisplayList. - A + B - properties - links - propertyName: ElementType - propertyValue: Variable - moreProperties - propertyName: VariableType - propertyValue: MemProcessor - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - properties - links - propertyName: ElementType - propertyValue: Command - moreProperties - propertyName: CommandID - propertyValue: IDOfPlus - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - propertyName: VariableID - propertyValue: IDOfVarA - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - properties - element - - - - - - - - - - - - - - - - - - - - - - propertyName: LinkType - propertyValue: dataComm - moreProperties - - - - - - - - - - - - - - - propertyName: DataType - propertyValue: inherited - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - properties - moreLinks - - - - - - - - - - - - - - - - - - - - - - propertyName: LinkType - propertyValue: dataComm - moreProperties - - - - - - - - - - - - - - - propertyName: DataType - propertyValue: inherited - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - moreLinks - - - - - - - - - - - - - - - - - - - - - - element - properties - links - propertyName: ElementType - propertyValue: Variable - moreProperties - propertyName: VariableType - propertyValue: MemProcessor - moreProperties - - - - - - - - - - - - - - propertyName: VariableID - propertyValue: IDOfVarB - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Notice that variables are identified by an ID. The Visualizer keeps the visual representation of each variable. The - Modifier receives data about the visual appearance of each variable from the Display (eg a string of the variable name). - The data comes inside a GUIGesture sent from Display to Modifier. The Modifier must relay this information directly - to the Visualizer. The Modifier does not keep this information, nor does the syntax graph hold any indication of the - visual appearance of variables. Many variables are visually represented by strings, so the Visualizer would store such - a string. The font of the variable, however, indicates properties of the variable. For example, a memProcessor has a - different font than a level-below SyntacticVariable. Each kind of variable is rendered in a different font, with different - effects. The font and effects are chosen by the Visualizer, and correlate with the properties of the variable. The - properties are stored in the syntaxGraph. - Likewise, the visual representation of a command is also kept inside the Visualizer. - Notice as well that when implemented in Java, for example, all property names and all property values can be enumerated - types. One complication is that some command names are custom and generated during entry of a syntax graph, and - the variable IDs are all generated during entry of the syntax graph. Thus, in Java, propertyValue is likely to be an - integer that is correlated to an enumerated value. The integer will be used in a switch statement. There will be a fixed - number of propertyNames for EQNLang, so that will be an enumerated type. - propertyName: SyntacticStructureType - propertyValue: syntacticPatternRoot - moreProperties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hierarchy (Dependencies) of PropertyNames and PropertyValues in EQNLang - t. - propertyValue: Name - propertyName: TypeOfNamed - propertyValue: MemProcessor - propertyName: ElementType - propertyValue: Command - propertyName: CommandID - propertyValue: IDOfTheCmd - propertyName: NameID - propertyValue: IDOfTheName - propertyName: DataType - propertyValue: inherited - propertyName: SyntacticStructureType - propertyValue: syntacticPatternRoot - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - propertyValue: SyntacticLink - propertyName: JavaClass - propertyValue: SyntacticElement - propertyValue: NameLink - propertyName: LinkType - propertyValue: dataComm - - - - - - - - - - - - - - - - - propertyValue: Structure - propertyValue: Processor - propertyValue: SyntacticSearch - propertyValue: Pattern - propertyValue: Syntactic - Treat constants as mem processors. So, for example in custom Tensor notation, - the index-column is a Structure ElementType, and so is the Tensor Index - that goes into it. That Tensor Index has a link to whatever is seen at that - point. It could be a name that stands for a processor that will be sent from - somewhere else.. in this case it is a Name ElementType, with a dataComm - link to whatever syntacticPattern sends the data. Sending data is sending a - processor containing the data. - Or, the Tensor Index could be a name that attaches to some other bit of syntax. - This is the thing where have a complex expression and just assign a - syntactic-level name as a short-hand for that expression. (What about - syntax-embedded re-writes? This is what SyntacticSugar is in Scheme, and - what a macro is..) - Or, the Tensor Index could be a constant. In this case the element is a - Processor. Will have probably a property for Processors, that can put in the - syntax directly, that they are a constant-containing processor, and what the - constant is. - Pattern I'm seeing as a from-into pattern.. it's not a command, because - - - attached means correlated-to) - - (need some way of getting at the concept of srcManipulators that are - embedded.. ie, some code specifies a re-write to other code that takes - place before the other code reaches the translator. Some sort of notion - - that specifies the re-write to be performed on other code.. Same notion - as in the different kinds of variables.. one kind is used to match, to - specify the from-into pattern.. the second kind of variable, sitting right - next to it, is not used when detecting matches. There could be two of - those also, but they are not looked at by the match-detector. However, - after the match detector is done, have a from-into pattern that has those - second kind of variable in it.. NOW those become active, when the re- - writer kicks in. The re-writer will see those and perform substitutions. - So, the distinction is which processor treats them as semantic info vs - - - - - is the macro-notion.. something that operates on the source code as - data devoid of semantic meaning. Whereas the re-writer treats the - source as does have semantic meaning.. that's the distinction between - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - propertyValue: syntacticStructure - - - - - - - - - - - - - - - - - ? not sure what to do here ? - ? not sure what to do here ? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - propertyValue: SyntaxGraph - propertyValue: ?Link? - The SyntacticStructureType is for partitioning into whole syntacticPatterns.. it - is used to find all the structure elements that go with each root element. - This is used when positioning shapes and deciding the scaling. All shapes in a - single syntactic pattern will get the same scaling. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ExternalTunneller - - - - - - - - - - - - - - - - - - - IntegrateEqnManipulator - - - - - - - - - - - - - - moreElems - moreElems - moreElems - - diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Dc_26___Syntax_Graph__CTOS_to_GUI_and_Custom_Syntax_Design_exported.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Dc_26___Syntax_Graph__CTOS_to_GUI_and_Custom_Syntax_Design_exported.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1300 +0,0 @@ - -Master slideSlideDrawingDrawingDrawingDrawingtokenTypestate tokenType allowed inside each box -- tokenType is more than just visual, a tokenType exists for each type of thing can be displayed..-- note that there's one tokenType, italic, for a variable that is an input, and a different tokenType for a variable that is a “constant”.. ie, a constant-variable is still there after the “into” is complete, as a variable.. whereas the italic-input-variable will be replaced (an italic-input-variable on the LHS == a box in the “from” and one on the RHS == a box in the “into”)..-- there is a tokenType for integers, a tokenType for dimension that can be placed in the index position of a tensor, a tokenType for variable, a tokenType for input, a tokenType can be defined to indicate any sort of “extra” information, a specific place that tokenType can be used, along with restrictions on the characters (ie, one can define a tokenType that can only have the integers from 1 to 50).. or can define a tokenType that one must query a processor, during evaluation of a grammatic sentence, to find out what the allowed character-values are (for example, ask the particular TensRep what is its working dimension, or attach the dimension as a value to the tensor-phrase, and make the tokenType only take values from 1 to that dimension --> this would be compatible with the way Gabe wants to use Tensors for his electron-states thing, where each tensor has a different dimensionality == number of allowed states or something like that.NOTE: have stopped using “font” and instead use “tokenType”DrawingDrawingnodeType: commandRootDrawingcommandName: TensRepOuterProdDrawingIndexedTensRepDrawingDefining Custom Tensor NotationDrawingDrawingIndexedTensRepDrawingDrawingLHDrawingRHDrawingDrawingDrawingcommandPatternName: generateDrawingresolvesTo: IndexedTensRepDrawingDrawingnodeType: boxPhraseDrawingTensorIndexDrawingDrawingTensorIndexDrawingDrawingIndex1DrawingIndexNDrawingDrawingDrawing. .DrawingTensRepDrawingDrawingTheTensRepDrawingDrawingTo use the “. .” first place a child with just the root name. Then use the standard GUI gesture to indicate that it is repeated. The “. .” and the second child appear, along with the “1” and “N” concatenated to the names. DrawingBoth AbsTens and TensRep use the same TensorIndexDrawingsyntaxDataType: IndexedTensRepDrawingA child is added via a GUI gesture, then a name for it is entered. The arrow and the box it points to are automatically popped up.Each child box is labelled with a syntaxDataType. A drop-down list is available that has all the known syntaxDataTypes. It is important to remember that a syntaxDataType is not a data type, and doesn't define a data type. However, each syntaxDataType is named the same as a corresponding data type. The syntaxDataType appears in the syntax tree in the position that a variable of that data type appears or a command that resolves to that data type appears.So, the LH child could be, for example, another TensRepOuterProd command OR an IndexedTensRep variablePhrase, both of which are syntaxDataTypes DrawinglangType is where the language-type of the phrase is stated. This node defines what something of the “IndexedTensRep” type is.DrawingThe nodeType, langType, commandName, commandPatternName, and produces are all standard fields defined in the “syntaxTreeNode” data types that are part of the OS Interface standard.DrawingA GUI gesture is used to pop into existence a “syntaxTreeNode” box. The label “nodeType” is in the box, and a drop down list is available with the standard node types, accessible via key gestures, the way “California” pops up by successively pressing “C” in the “state” entry field of a web page.The node type determines the other fields in the box. Those also have drop-down lists availableDrawingThe boxes are not seen during use of the custom notation. They are only seen while defining the syntax tree elements that the editor will create in response to commands coming from the GUI.The GUI actions described in annotations here are actions that happen during the syntax-tree element definitions.Other GUI actions will happen when creating equations that use the custom notation. DrawingA boxPhrase consists of a box plus a number of operators that take the box as input. The operators may be defined to apply in any sequence or together as a collection or sub-collections. However, the collection of operators must only take the one box's contents as input. The data type that the box's contents resolves to must be stated, and the data type of the result of the entire collection of operators must be stated. If not all operators have to be applied at once, then the result of applying only a few is another boxPhrase of the same type, but with fewer children.This is a bit confusing because a boxPhrase is a syntax tree node type, not a data type that flows between processors. However, because of the requirement of partial evaluation down to primitives before translation, one can act as though a boxPhrase were a data type that flows between processors. In fact, one can partially fill in a boxPhrase and send that as an input. The boxPhrase must resolve, once all children have been filled in and all the operators have performed, to the data type of whatever box the partially filled boxPhrase has been placed in.For example, a pattern-function that takes an IndexedTensRep may have an IndexedTensRep that has empty positions (displayed in the equation as boxes) placed in one of its input positions, as long as the pattern fills in the empty positions, so that partial evaluation can reduce all the way to primitives. Also, boxPhrases can be nested, so that the result of applying one subset of operators is the input to a further set of operators.DrawingDuring use, a box can have placed in its position a boxPhrase, a commandRoot, a name (where a name appears as a variable in an equation), or a constant (of the box's type).A boxPhrase can be placed in the position of a box that takes such a boxPhrase. Doing so implies that the operators of the phrase should not be evaluated until after the boxPhrase is substituted into the box's position, during partial evaluation.A boxPhrase can also be placed inside a box whose data type is what the boxPhrase results to. In this case, the partial evaluator is free to perform the operations of the phrase before or after replacing the box with the phrase, whichever is most convenient for the translator.DrawingIndexedTensRep is actually an interesting example of a boxPhrase. During use, the children-boxes can have placed in their position variables, or abstractIndexes, or integers from 1 to dimension.The behavior is different depending on what is in the position of each child box in the syntax tree. If it is a variable, then there is no behavior, this is just a symbol used in the definition of a function-pattern to indicate matching between LHS and RHS. Each match becomes an arrow between a box in the “from” to a box in the “into”.If it is an integer, then the operation is a selection.If it is an abstractIndex, then the syntax tree is searched for matches. Any pair of matching abstractIndexes are replaced by an operation on the TensRep data structure that the box-of-the-boxPhrase resolves to. This operation is performed at run-time. It iterates from 1 to the dimension of the pair of indexes. At each value of iteration, both matching abstractIndexes are replaced by the iteration value and a selection with that pair of index values is performed. The result of selection is added to a running sum of the selection results. That sum is the final answer. (note if not all the abstract indexes match up in some pair, then the result will be a TensRep that still has multiple indexes.)DrawingresultDataType: TensRepDrawingDrawingCTOSSpaceDrawingExternalTunnellerDrawingName SearcherDrawingdataHolder1DrawingdataHolder2DrawingdataHolder3DrawingCD-ROM(Appears as anExternal processor)DrawingAuthenticatorDrawingCreatorDrawingImporter-ExporterDrawingDrawingDrawingDrawingDrawingOther CTOS InstanceDrawingWeb ServerDrawingDrawingDrawingFooBarWorkSpaceDrawingDrawingDrawingDrawingGroupDrawingDrawing//images from HubbleFormat: RGBDrawingDate created: Jan 23, 2006DrawingDrawingDrawingMyEqnsDrawingreceive processorDrawingDrawingDrawingimageHolderDrawingGabeImageProcessorDrawingGroupDrawingIntegrateDrawingfnDrawingresult = DrawingresultDrawingDrawingDrawingDrawingxDrawingDrawingfn dx DrawingCreatorDrawingDrawingTranslatorDrawingDrawingreceive processorDrawingDrawingDrawingGroupDrawingDrawing//Predicted ImagesFormat: FoobarDrawingDate created: Jan 24, 2006DrawingimageHolderGroupDrawingGraphic -DrawingDrawingCreatorDrawingTranslatorDrawingDrawingGroupDrawingz := 22x = foo( x, y ) + zxDrawingbarDrawingxDrawingyDrawingDrawingDrawingFooBarProgramSpaceDrawingIntegrateManipulatorProgramSpaceDrawingDrawingIndexedTensRepDrawingDrawingnodeType: boxPhraseDrawingTensorIndexDrawingDrawingTensorIndexDrawingDrawingIndex1DrawingIndexNDrawingDrawingDrawing. .DrawingTensRepDrawingDrawingTheTensRepDrawingDrawingsyntaxDataType: IndexedTensRepDrawingresultDataType: TensRepDrawingDrawingIndexedTensRepDrawingModifierDrawingmodifyCommand: addIndexedTensRepDrawingDrawingnodeType: leafDrawingsyntaxDataType: TensUpperIndexDrawingDrawingTokenTypeDrawingTensDimensionDrawingTensAbsIndexDrawingsyntaxBaseDataType: TensIndexDrawingmodifyCommand: addTensUpperIndexDrawingDrawingnodeType: leafDrawingsyntaxDataType: TensLowerIndexDrawingDrawingTokenTypeDrawingTensDimensionDrawingTensAbsIndexDrawingsyntaxBaseDataType: TensIndexDrawingmodifyCommand: addTensLowerIndexDrawingThe syntaxBaseDataType is similar to syntactic sugar for putting an OR list inside the child boxes of IndexedTensRepAlso, remember that this specifies what the syntax tree will look like, this is not an entry in the syntax tree itself. In the actual syntax tree, there will be either an integer or a letter in the node. Here, have to say that either of those is okay to put in this position (TensDimension is a TokenType that can have as its characters an integer from 1 to the number of dimensions that the TensRep this index is tied to has.DrawingA TensRep is a data structure. So in the spec-of-the-syntax-tree, there is no node for one, there is only a node that says “a data structure of this type goes here”DrawingThis notation here is what the programmer enters when defining custom notation. Each box states an EMPTY syntax node that gets added to the syntax graph in response to the command. The contents of the box state the TYPE of things that can be placed in the node by GUI gestures. This information is used by the Visualizer to generate GUI grammar that it adds to the DisplayElements it sends to the Display DrawingDrawingDrawingDrawingDrawingDrawingGUIDrawingNode: TensUpperIndexDrawingNode: TensLowerIndexDrawingTensIndexColumnDrawingThis specifies what the visualizer is to produce to represent the stated nodeDrawingThis specifies new GUI gestures that the srcWindow is to recognize, plus the command to be sent to the editor as a result of one of the gesturesDrawingThe modifier keeps track of the insertion pointand uses it to choose where to put the node or value.DrawingWhen the editor receives this command, it will give an error back to the GUI if the insertion point is in the wrong place.Also, after adding this node, the insertion point will automatically be moved to this node. Thus, the next command from the GUI should be an “addToken”. Or else a move-insertion-point followed by some other command.A token is a string of characters plus an indication of the tokenType.. so, a function-parameter can have the exact same characters as an expr-name, but they are displayed differently and interpreted differently by the translator. The function-parameter-token indicates that the tokenType is function-parameter-tokenType, likewise the expr-name comes in a token that indicates expr-name-tokenTypeThe function-parameter is displayed italic, while the expr-name is displayed normal (normal is the default expr-name “rendering font”, set as a default in the visualizer)Note: used to call “tokenType” “font”.. changed it for clarity.. the name “tokenType” matches the function it serves better..DrawingMenu:Tensor, Entry: UpperIndexDrawingDrawingsend: addTensUpperIndexDrawingkeySequence: /TensUpperIndexDrawingTo Do s:0) specification of syntax data structures:-- what fields each has-- the purpose of each field: how it is used by processors: Visualizer, Display, Modifier, ReWriter, Primitive Processors-- the valid contents each field can hold-- what each content causes each of the other processors to do: V, D, M, RW, PP1) specification for one visualizer. The spec says:-- what DisplayElements the Visualizer should generate, for each given SyntaxNode-- how to position the DisplayElements on the canvas-- how to scale the DisplayElements 2) specification of how a programmer states the grammar.-- EQNLang's initial grammar is stated with the same terms-of as grammar of custom syntax-- The grammar is stated in visual terms-of. The grammar is stated as what GUI gestures are allowed when a given link-end is focused-on, or when blank canvas is focused-on.(look at issues about grammar, about how editor tells GUI when invalid commands have come in, or an invalid order, like trying to move on before finished)Grammar of the visual-elements structure itself, separate from syntactic structure and semantic structure. Eg, have boxes for each column of tensor indexes, and have that composed of an upper and a lower: have to indicate can only have either an upper or a lower3) specify translation of GUI gestures to ModifyCommands-- what information must be included with each GUI gesture sent to the Modifier4) specify the modification to the syntax graph caused by each modifyCommandExamples:-] GUI gestures: describe a context, describe what programmer does, state the GUIGesture data-structure that goes from Display to Modifier as a result.-] State the modify command each gesture plus context is translated into--> Show the code that the programmer enters to cause that translation. Draw the visualization of the Translator code. This is what the programmer sees on their Display as they specify how to translate GUI gestures into modify commands-] State what the example modify command does to the syntax graph. Draw a partial syntax graph before and after the command. This includes the syntaxNode data-structure and the values in each field--> Show the Modifier code that specifies the behavior of that command. IE, draw what the programmer sees on their Display as they specify how the Modifier is to carry out the behavior of the modify command.-] State the DisplayList the Visualizer generates for the new syntax graph. Show the values in each field of the DisplayList. Show the indication of insertion point. Show the GrammarElements that state which GUI gestures are valid from each node and from each empty link.--> Show the code that specifies how the Visualizer is to translate the added syntax node into DisplayElements. This is the Visualization of the code the programmer sees on their Display as they write the Visualizer code.-] Show the Visualization of the modified syntax graphDrawingPalette: Tensor, Icon:<vector graphic>DrawingThe dashes indicate that it is a visual node but it doesn't displayDrawingFull Sequence of Custom Syntax Editing Session:The sequence of events, starting with GUI gestures, that builds an expression in a custom syntax, including the sub-tree being sent to the command-generator, a new syntax-tree being generated and added to the programSpace, and the name of that newly generated command being sent back to the editor and inserted in place of the original “generateCommand” value in the command-name field of the command-node.-] User is sitting at a machine, invokes the local-to-that-machine sequence to create a CTOS GUI. This GUI is a program running locally on the machine under the local OS. It is coded to know the protocol for connecting to and communicating with a CTOS instance. This GUI can create several Displays. Each Display can specialize to many kinds of behavior. A Display is a window that is connected to the CTOS Instance. Each Display has one processor that has that Display's behavior-token. The Display specializes its behavior to the processor that holds its behavior-token. For example, if a srcHolder that holds EQNLang source has the behavior-token, then the Display has an icon palette that is specific to EQNLang srcHolders, and it has mouse-menus that are specific to EQNLang srcHolders, and so forth. That same Display can have its behavior-token moved to some other Holder or Space processor, in which case its icon palette and mouse-menus and other behaviors will change. The top-level processor of the CTOS Instance is a CTOSSpace processor, which often holds the behavior-token for at least one Display that opens upon successful authentication by the user.-] User is presented with a list of known CTOS instances in a dialog, with a way to specify or navigate to more. User picks one.--> A Display is created and its behavior-token is given to the top-level (CTOSSpace) processor of the chosen CTOS instance.-] User is challenged inside the Display and performs authentication--> Triggered by successful authentication, a hierarchy of visualizers is created, one inside each visualizable processor that is visible to the authentication. (or, more likely, just inside a default set of initially visualized processors, maybe remembering what was visualized the last time this authentication was connected to this CTOS Instance). This hierarchy generates a visualization of the CTOS Instance and sends it to the CTOSSpace specialized Display.--> The DisplayList generated by the visualizer hierarchy is painted in the CTOSSpace specialized Display..-] User focuses on a srcHolder in the Display and invokes gesture that creates a new Display whose behavior-token is given to the focused-on srcHolder.==== sent to the srcHolder, which modifies the meta-data of the syntax-tree node that has the focus. The editor also looks for the sub-node that had the insertion point most recently, and marks that node as having the insertion point.--] The visualizer notes the changes in the meta-data and sends a diff to the srcWindow.--] The srcWindow receives the diff and redraws the thing that has focus and the thing that has the insertion point. The user now sees the visual cue of where the focus and insertion point are.2) User enters zoom gestures and pan gestures to get to a section they want to modify--] focus and pan are completely handled by the srcWindow. The srcWindow receives a graph of visualization objects. Each object states a size plus a position relative to other objects. These positions are all on a canonical grid. The srcWindow keeps a zoom factor that is the ratio between canonical distances and screen-pixel distances. The srcWindow also keeps a clip-window that is what gets painted up on the screen. Pan moves the clip-window around and zoom changes the size, in canonical units, of the clip window. Then the clip window contents are multiplied by the zoom factor to give pixel-unit sizes, and the result is drawn in the paint area of the srcWindow.3) User pulls down the Tensor palette and selects the icon for the outer-product command--] The GUI was told what command to send to the srcHolder for this particular icon when the Tensor Custom Notation Package was loaded into the GUI. This command is sent to the srcHolder's editor.--] The editor was told what syntax-tree-node to add for this command when the Tensor Custom Notation Package was loaded into the GUI. The editor adds this node, with all empty children and attribute fields. The node is placed where the insertion point was and the insertion point is moved to the first child of the command node.--] The visualizer knows what visual elements to send as the visual representation of the newly added node. It was told what visual elements to use by the Tensor Custom Notation Package. It sees the new node added by the editor and generates a tree of visualization elements that gets rendered by the srcWindow. The user sees the command-symbol plus a bunch of empty boxes, one empty box for each child and for each “seen” attribute.4) The user then goes about moving the insertion point with arrow keys or mouse or other shortcut keys. At each point, they do GUI gestures, to enter more nodes or to enter tokens (a name is a token). The user has GUI gestures available to indicate the tokenType (pull-down list, icon, menu item, shortcut key, key-sequence). At some point, all the children of the command-node have been filled in. At this point, the editor sends the command-sub-tree to the programSpace, with the command to give it to the srcHolder-type's-custom-processor called commandGeneratorProcessor.That is, when a srcHolder is added to a programSpace, that srcHolder is asked for the name of the spec of any custom processors the srcHolder wants the programSpace to make. The programSpace takes the specs and makes processors from them, then hands back the name of each created processor (such a created processor can be a spawner).The EQNLang srcHolders have the spec of a CommandGeneratorGenerator processor. This processor is created by the programSpace, if it doesn't already exist (if there is another EQNLang srcHolder already in the programSpace, then the commandGeneratorGenerator will already exist). Next, any custom notation packages that the newly added srcHolder requires are loaded in. The srcHolder for EQNLang is specialized especially for EQNLang. Part of the specialization is that each keeps a list of all customization packages that are used by any of the nodes inside that srcHolder. When the srcHolder is added to a programSpace, or when a new notation package is loaded into the srcWindow of a srcHolder, then some stuff happens: The customization package includes the specs of custom-command-generators. These specs are sent by the programSpace to the CommandGeneratorGenerator. The CommandGeneratorGenerator creates a new processor out of each spec. Thus, the commandGeneratorGenerator knows about one commandGenerator for each kind of custom-command node that is in any of the EQNLang srcHolders that are in the programSpace.want this whole system to be generic. So, no matter what language, the srcHolder for that language is invited to give specs to the programSpace and have the programSpace turn those into processors and give back the names of those processors. Thus, the commandGeneratorGenerator is created via a generic mechanism. The programSpace has nothing custom about it that was needed for the commandGeneratorGenerator. The programSpace only has the one generic “give me specs that you want turned into processors” step that it performs during initial add of any srcHolder.Now, when a new custom-command-node is finished, then its sub-tree is sent by the editor to the commandGeneratorGenerator, which hands the tree off to the commandGenerator for that type of node. The commandGenerator has all the information it needs within the sub-tree. It performs whatever its code specifies, taking info out of the sub-tree it was handed and building a new syntax-tree. The new syntax-tree is a “from-Into” tree. The new from-Into tree is given some randomly generated name. The name is sent back to the srcHolder that sent the custom-command sub-tree. That srcHolder then removes the entry in the original custom-command sub-tree that said “commandName: generated” and replaces it with “commandName: <random-generated-name>”. The commandGenerator also hands the from-into tree to the programSpace to be added as a new library srcHolder.Now that custom-command node is just like any other node that has the command-name of a from-into tree.GroupDrawingTensor Outer Product Command GeneratorNeed: to know how many indexesWhat it does: takes two TensReps, produces a TensRep that has as many indices as the sum of the indices of the two input TensReps.The value of the outer product is: take any valid replacement of abstract indices with integers, for all indices of both TensReps being multiplied. This will select a single cell from each TensRep being multiplied. The product of those two cells is the contents of the cell selected by the same substitution of abstract indices with integers performed on the product TensRep.So, a simple algorithm is to do a series of nested FOR loops. One FOR loop for each index of each TensRep. The innermost loop's body takes the index-var values from the outermost loops and uses them to access one cell of the left-most TensRep's multi-set. It then takes the values of all the inner-most loops and uses that set to access one cell of the right-most TensRep's multi-set. It multiplies the contents of the two cells, then puts that value into the cell accessed by the values of all the index-variables on the result TensRep.Another way to state this is with invariants:state the boundaries for each index-position, and state that the result-cell receives the product of the two multiplied-TensRep cells:DrawingR = A * BDrawing0 < j < 4Drawing0 < i < 4Drawing0 < k < 4Drawing0 < l < 4Drawing0 < m < 4Drawing0 < n < 4Drawingl mDrawingnDrawingiDrawingjDrawingkDrawingiDrawingjDrawingkDrawingl mDrawingnDrawingNow, when a user enters a Tensor Outer Product, are restricting it to only take TensReps as inputs, not AbsTens nor AbsTensFields nor TensRepFields.There can be any number of indices, and in any order of raised and lowered.Also, TensRep is a data structure that consists of a multi-set (a multi-set is a primitive of the language), plus a vector indicating raised or lowered for each index-position (ie, contravariant or covariant), plus the dimensionality of each index-position (in general a TensRep can have a different dimensionality for each index-position. Gabe uses this in his Tensor notation for energy states of bound electrons).So, the command generator will examine the index-positions of each input to the outer-product command. For example, the user enters:DrawingR = A B + IGroupDrawingDrawingDrawingDrawingThis needs to be translated into language primitives -- each variable-name resolves to a TensRep or an IndexedTensRep-- the outer-product command has to handle any combination of number and dimensionality of indices of its two inputs.-- The identity TensRep must have the same number of indices, the same raised-lowered, and the same dimensionality as the result of the outer product.-- The outer-product is a “Run-time or generated command”. So it has no “commandName” that can be used to look up a from-into pattern.-- If the number of indices of A and B are known at translation time, then a command can be generated and its name put into the syntax tree as the from-into pattern to use-- Otherwise, a “plugin” is supplied that runs at run-time to perform the command. The plugin looks at the data-structures it is handed and checks compatibility (rules about number of indices, raised vs lowered and so on). It then performs a generic outer product code that has one loop. A vector of index values, plus the two limits for each, is kept. The loop increments the lowest index each time through. When that lowest reaches the upper limit, it increments the index above it, then resets the lowest to its starting value. When the one above it reaches its upper limit, it increments the index above that then resets to starting value, and so on, until the highest index gets incremented to its limit (limit checked against is one larger than the largest value want the index to take). This generic code works for any arbitrary number of indices and dimensionality of the input TensReps. However, good luck optimizing it or parallelising it. Want “lint” to tell programmer that it is much more efficient if they can state somewhere the range of number-of-indices the input TensReps can have, or state the most-likely number-of-indices (generate commands for the most likely values and save this generic as a catch-all.. at run-time a switch on the sizes jumps to one of the generated commands or to the generic).-- would be nice if the invariants form could be used somehow in the generic catch-all DrawingSequence of Programmer Editing Code Take 2Editing of code takes place via the MVDM pattern. This stands for “Model, Visualizer, Display, Modifier”.-- The Model is the syntax graph.-- The Visualizer reads the syntax graph and generates a DisplayList.-- The Display paints the DisplayList, for a person to see-- The Display also accepts GUI gestures such as mouse-clicks, keyboard strokes, mouse movements, icon clicks, etc.-- The Display packages the GUI gestures together with relevant information and sends package to Modifier-- The Modifier translates packaged GUI gestures into modification commands-- The Modifier performs the modification commands, which change the syntax graph-- The Modifier notifies the Visualizer of the changes made to the syntax graph-- The Visualizer generates either a DisplayListUpdate or a new DisplayList and sends it to the Display-] GUI gestures are used to construct a syntax tree-] As the tree is constructed, it is visualized then displayed-] The Display has a set of standard DisplayElements that it understands. DisplayElement is a standard data-struc that the Visualizer and Display both understand.--> A BaseDisplayList replaces everything that used to be on the Display's canvas.--> A DiffDisplayList modifies whatever graph is already on the canvas. This allows the visualizer to only send diffs when it updates. This is especially useful for just edit-point movements or sub-tree focus changes or selection changes (edit-point is where the cursor is blinking.. also known as the insertion point.)-] Upon receipt of a DisplayList, the Display updates its canvas and repaints it. Changes in focus, or movement of the edit point, etc, show up this way.-] GUI gestures are relative to the edit-point, the focused-on-sub-syntax-graph, and the selected syntax-sub-graph-] The gestures are packaged and sent to the Modifier-] The Modifier translates the gestures into modification-commands.-] The edit-point, focused-on sub-syntax-graph, and selection-sub-syntax-graph are owned and changed by the Modifier. The changes are sent to the Display via the Visualizer.-] The Modifier modifies the syntax-graph, including adding new nodes, moving focus, moving edit point, and so on.-] Modifier tells Visualizer the changes it made. It sends a list of nodes that have been modified, including those entering focus and those leaving focus, and those that gained edit point and those that lost edit point. And those that entered and left particular selection-collections.-] Visualizer uses the list of modified nodes to decide if it is better to send a diff or a new base. If a diff, it uses the modified list to construct the diffDisplayList.-] When editPoint changes, the Visualizer determines the effects this has on valid GUI gestures, and sends the new valid GUI gestures with each element in the diffDisplayList or baseDisplayList it sends to the Display. For example, when editPoint is on an empty link, and the programmer does the “show valid choices” gesture, the GUI should display all the kinds of gestures that are valid to perform on that point. The Visualizer code that the programmer creates as part of creating custom syntax includes specification of how to determine the valid gestures for each link and node.-] The programmer chooses among the valid options, or types the beginning of the option to have it filled in by the Display, or whatever-] the Display packages the gesture and sends it to the Modifier.RepeatDrawingGUIGesture to ModifierCmd Translations for Tensor Notation1) To be filled in..Drawingexternal GUIs for coding toolsThe srcHolder, workSheet, and programSheet all have visualizers and editors. The OSInstance, in fact, is a specialization of workSheet and has a visualizer and Editor itself. Anything a person sees is generated by a visualizer (there can be many variations of visualizer for the same thing, each displays in a slightly different way, according to personal tastes)Any modifications made by a user looking at a GUI are made by interacting with a tool that is an external processor. This tool draws the visualization, accepts GUI gestures, packages them with their relationship to the drawn visual elements, and sends them to the editor, which is inside the OSInstance, attached to whatever processor is being visualized.So, there's a visualization of the OSInstance, which appears as seen above.. this shows processors, namespaces, and inclusions.. one can delve down into any processors that appear in the OSInstance that one's Authentication has the Ability to see.The OSInstance visualization is focused on seeing the existence of processors and the inside-vs-outside relationships they have to each other.However, a workSheet visualizer may instead want to hide the existence of processors. It may, instead, show the equivalent of a MathCAD worksheet.. visualize src as being on a sheet of paper, feeding into a symbol that represents a srcManipulator, with the src that srcManipulator was created from available in a different visualization.. so, everything one sees is symbolic.. meanwhile, on the OSInstance Display, the srcHolder shows up instead of a visualization of the source inside it, and the srcManipulator shows up as a processor that is placed by a creator, and it shows the srcHolder that srcManipulator was created from as a processor. The OSInstance view might have a small window on top of srcHolders that give a glimpse of what is inside as a visual aide for the viewer..The essential point here is that the person viewing can use either the OSInstance visualization or the worksheet visualization to add new processors, change connections among processors, and so forth. Whatever is done in one Display will show up in the other Displays..DrawingProperty PatternsA property is a pattern. Something that has a property is something that matches the pattern. The pattern is what defines the property. The pattern is the essence of “property”. So, properties that are useful have from-into patterns. Anything that matches the “from” has the property. Anything that has the property can be re-written using the property's from-into pattern.For example, distributivity is a property. The from-into pattern is that anything that matches, it is known has the underlying syntax-tree shape of something applied to the result of a calcluation.. IE, “x( y + z ) means that “x times” is applied to result of “y + z”.. the distributive from-into says that can take the thing being applied second, the “x times” and do it first to each input inside the calculation was waiting for.. so, the “y + z” is the calculation the “x times” was waiting for. So, the from picks out the y and the z, those each have the “input” property, and the from picks out the “x times”.. the into says put each input with the wait-er, then make the results of those the inputs to the inside-operations.. “x times” is the wait-er, the “ + “ is the inside operation, the “x times y” and “x times z” are the results of the into, so have “(x times y) + (x times z)” where the parens means the order of performing the operations (performing an operation is performing a from-into by the way)”So, a Type in a progr language is exactly a property. Character strings of digits must match the “integer” pattern. The integer pattern is a string containing digit characters. The pattern is a complex one because number-base calculations have to be performed to determine if the value of the string is larger than what matches the integer-pattern.. IE, in Java, it is, what, plus or minus 2 billion something or other..So, the from-into pattern is also complex.. commands have a format of what they accept. IE, in formal definition of processor, the processor has an interface. The interface is defined by a number of patterns. Anything that matches the interface patterns can be accepted by the processor, and will give the behavior specified as the processor's behavior. Remember the specification is what was used to make the processor.. but the specification is NOT the processor. The processor is made from other processors, and so on.. Giving a processor something that doesn't match its interface's patterns doesn't mean the processor won't do anything, it just means that the deriving processor(s) won't show behavior that corresponds to a derivation of the Specification the derived processor was made from.So, the into for a Type is.. what? It is acceptance into all interfaces that use that type-property's pattern as what they accept?Hmm.. have to think some more about that.. when match to a property-pattern is used as a “guard” rather than as a scheduling constraint -- (seeing the opportunity to apply the from-into pattern attached to a property-pattern as the opportunity == scheduling-constraint on scheduling the from-into command. Every re-write is a command.. the application of a from-into is a step of computation.. the perform of a re-write is a computation.Well, there you go.. in both cases, match to property-pattern is used as a scheduling constraint. In the case when the property has its own from-into pattern attached, then match to the property-pattern is the constraint on scheduling the property from-into. In the case of some random command specified that the inputs have to match the property-pattern, then match to the property-pattern is a scheduling constraint on scheduling the random command.Both cases are the same, both are match to property-pattern IS a scheduling constraint. The only difference is that a command attached to a property-pattern is one that someone else has written, and is widely known. Whereas a random command inside a program is a relatively recently written command, and is known only to a few (only those who wrote the program).. The only difference is the USE by people.. that's it. It's just a logistical difference that is a property that people calculate.. the property here is the pattern of when the command was written down, by whom, and how widely known it is.. Okay, so back to Types. They are property-patterns, like all other properties. The one thing is that there is a higher-level property pattern at work. The set of property-patterns that match a logistical human-usage pattern is the set of programming-language Types. The usage pattern is that the Type property-patterns are used during specification creation. A specification includes defines of interfaces. So, in a procedure, for example, one states the type that each parameter must match. myProcedure ( int A, float B ).. the int and float are saying what patterns must be matched by the things communicated in to a processor made from the myProcedure specification.The specification is passed through a source manipulator that performs pattern matching. For every communication specified to be POSSIBLE between processors, it checks that the communicated thing will match the interface Type property-patterns.By the way, in a specification, when one writes down the usage of a procedure inside another procedure, one is stating that a communication is possible between two processors. One processor *would be* an instance made from the calling procedure, the other would be a processor made from the called procedure. What's important here is that the specification is not performing a communication. The specification is only saying that, when this spec is used to create a processor, there will be two created processors in existence, and those two will perform communication. The “when” is the key here.. a single procedure specification can be invoked in many places.. this means that when a calling procedure specification is written, it is not known what specification will be used to create the processor hooked up in the called-procedure position.That's the key point, is that stating a called-procedure is only stating a communication interface. It is only when processors have already been created and a communication takes place between the calling and called procedure-derived-processors that it is known what the processors are, and what type-property-patterns have to be satisfied to perform a valid scheduling inside the calling processor to the called processor.So what this means for the syntax tree is that Type is a property-pattern. So, include general property-patterns in the command syntax-nodes. Perhaps include a-priory known-to-satisfy property-of-properties sets. IE, include a Type set of property-pattern assertions (defines).Seeing something like a linked list of properties. -- should command-nodes have them? Yes.. many re-writes are a-priori known to be valid for commands. Hmmm.. think some of those rules are for combinations of commands.. let's see.. the distribution did above, it worked for times outside, with plus inside.. doesn't work for times outside and.. ? Hmm, is it possible to create some kind of complex compound binary operation for which such a distribution does not work? IE, if perform multiply first, then do the binary operation, get a different result that doing the binary operation then multiplying the output. Well, YES, any non-linear binary operation will give a different result if do the multiply to the inputs before doing the non-linear binary vs doing the non-linear binary then multiplying the output.So, that's the answer.. yes, only some combinations satisfy the from for a given from-into re-write. Means that the property list has to be done in a way I have to think about a bit more.. In any case, the Type property I can define to be universal, just need to attach to inputs to commands, and attach to results from commands, and make constant be an output from a built-in command. And program-inputs be, inside the program, outputs from an input-port command, or something.. they're just inputs to the program's top-level commands.. maybe a stream of them..By the way, theorems are each exactly a property-pattern. They have a pattern for what satisfies the necessaries of the theorem, and they have a re-write rule. The re-write rule is the “application” of the theorem. IE, when doing a proof, getting from one step to the next by invoking a theorem is doing two things. First, it is asserting that the from-line matches the theorem's from-pattern. Second, it is stating the result of performing the re-write.Finding a proof is then the same as playing chess.. One performs a search, in the middle of the search, one is pattern matching to the search itself, and using “heuristics” to guide the search process. The search is going about finding all theorems and other re-write rules that have either a from or an into that a heuristic says might get closer to a sub-goal in the search. The search then tries all kinds of sequences of performing re-writes until it finds a sequence that goes from givens-patterns plus hypothesis-pattern to goal-pattern.The thing people do that automated don't yet are two things: one, spontaneously recognize patterns about the search process itself. Two, identify “keys”.. what is that? Fundamentals, what am I doing when I do that? Identifying the “hard” parts.. identifying pattern that matches across a wide range of inputs.. the raw input-data is put through re-writes, and those re-write results are put through more, and so on, then recognise a pattern among the output of rewrites that are several layers up. That's equivalent to the heuristics in pattern-search, I believe.. yes, if patterns can spontaneously be recognized in the outputs of re-writes that are at any arbitrary layer up, then patterns about patterns can be popped into existence. That is a key thing that must be automated.. thinking perhaps have already accomplished this in statistics and machine learning stuff.. could grab into this framework and see what an inorganic thing would come up with for heuristics in guiding its searches for proofs. And see if it can use multiple conflicting goals and balance them.. goal of maximizing aesthetic pattern-match.. process the search-path by putting it through partial-matcher to aesthetic patterns.Would need to include the aesthetic partial-pattern match output as part of optimization that is performing the search. In real life, don't get perfect pattern matches when search for a sequence of re-write rules to apply.. so, for example “I'll tell John I have to wash my hair” is a re-write rule that the person has performed a search for. Their end-goal was “get out of date” pattern, their start was “he asks me” pattern. They did a search of all that matched the start and some sequence got them to the end. They also did an optimization by considering partial matches to other patterns such as “how hurt his feelings are” and “will friends see that sequence as mean” and “how believable is the sequence to him”.. and so forth.. In the end, choose the sequence that maximizes the goals.. for her she might place high importance on “don't make him feel too far down in status ordering” which == part of “hurt his feelings” just “hurt” is processed outside of the recording spotlight for most people, so it is a primitive, a result from a point-to processor. Brain goes backwards.. in above was saying “what would break the distribution pattern?” Started with the into, and asked “what pattern would an input have to match to NOT satisfy any from-into that ends up here” or rather “what thing would an input have to match, so that it will fail all known from's that have this into”Hmmm, is that the same as doing multiply backwards to get division? “what input pattern in this position of the from would give this into” That's a statement of division.. given one input, the multiply from-into, and the final into, search for any valid second input that results in the given into.Hunh, I wonder if instead of having some primitive operation in neurons, if instead just have something that does a search, using the standard search thing, but below my recording device? When I invert a rule, am I just invoking a standard good-old-fashioned search?Crap.. battery gone.. this has been fun.SrcPhrase instead of syntacticEntity? One concept is a collection of src-datums, the other is a collection with a single syntactic meaning.. the syntax machinery handles a syntacticEntity as one thing..DrawingSyntax Graph NodesHow is the syntax graph used? What should the nodes look like?-- Have to be able to write code (like see to the left, when this was written) that says what node to add for each GUI Gesture that comes from the GUI processor. This “what to do” code includes information about what GUI Gestures are allowed relative to the new syntax node.. for example, adding a root of a compound syntactic entity enables GUI gestures for adding the sub-portions of the compound syntactic entity. Those GUI gestures only become possible to the person interacting after the root of the compound syntactic entity has been added.The Visualizer is responsible for telling the Display what GUI Gestures are allowed relative to each GraphicalElement. (Maybe should change the name to Visual Element..)So, on the long drive, seeing a few things:-- have case with Tensor notation where have the column things.. those are not visual, and they don't have any semantic meaning, they are purely mechanics of the grammar of the syntax.-- When do src manipulation, will have custom syntax, and a srcManipulator won't know what to do with this custom thing.. but when have properties attached, those are saying “from” patterns that the custom syntax matches, and so the “into” can be substituted in.. useful when making transforms looking for ways to fit efficiently onto hardware with part structure..-- Leaving re-writing till later.. only concentrate for now on something that enforces the grammar, allows custom grammar for new custom syntax, and is visualizable with custom visualization that turns the custom syntax into a standard GraphicalElement chain.-- When add a custom vector graphic, will have boxes denoting inputs placed at particular locations.. want those locations to be defined as part of defining the custom syntax.. the box locations are known by the visualizer but not by the Display.. the visualizer creates box GraphicalELements are the appropriate locations relative to where it places the custom vector graphic, and it sizes all appropriately. Thus, the visualizer receives code as part of the custom syntax definition that gives the visualizer the info it needs to place the boxes in the appropriate locations.. and then to put other symbols in those locations once the boxes get filled in via GUI gestures.-- The syntax graph nodes are only used for getting the grammar correct while building the graph.. so the editor receives info in the custom syntax specification that tells it what syntax-graph-element to place at the insertion point in response to a particular GUI gesture. The editor relies on the Display to have obeyed the directives given to the Display by the visualizer.. these directives cause the Display to only allow grammatically correct GUI gestures to be made by the person.-- The Visualizer receives information as part of the custom syntax spec that it sends along to the Display. This information is attached to each GraphicalElement and embodies the grammar of the syntax. The information tells the Display what GUI gestures are allowed in relation to each graphical element the Visualizer sends to the Display.These GUI gestures may be drop-down menu entries, or right-mouse menu entries, or valid keyboard strokes.. each menu entry is present only when that GUI gesture is allowed. From many GUI gestures, they are only allowed when a particular node is focused on. So, the mouse-menu and valid keyboard strokes change as the focused-on GraphicalElement changes.-- It is expected that many different types of Display will be written.. each will handle focus, and Display-relative commands like zoom and pan and probably font (but have to wait and see if practical).. and thinking some kind of intermediate thing specifies the GUI gestures that are valid.. then one Display can indicate the valid gestures as drop-down while a different one indicates them by icons on a pallette or something..-- It is expected that many different types of Visualizer will be created. It might be best to determine font in the visualizer rather than in the Display.. Font is important.. different fonts will have different semantic meaning.. for example, with Tensor notation, which has abstract indexes.. those indexes are characters.. the characters represent something that has meaning only in that they get matched with other such characters.. meanwhile something needs to represent free-choice inputs to a syntactic entity.. for example, may want to define something that has two free inputs on the left side, and has two holes on the right side where there are input boxes of a syntactic entity that have not been filled in. Need some way to indicate which of the left-side inputs should be shuttled over to which of the right-side holes. Can do this with arrows, but want to be able to do it with variables also.. so, have a special font to use for this purpose.. thinking an italic font.. so then in the case of Tensor notation, have on the right hand side a Tensor entity that has 6 index columns, with 4 of them filled in with letters.. well, those letters are literal for the FIRST re-write that takes place.. the two empty columns require that the left-hand side have a letter that matches to a same letter on the right-hand side in one of the empty columns. This is why different fonts are needed with different semantic meaning.-- Will have multiple Visualizers in each processor that can be visualized. Note that only Holders and Spaces can be visualized.. processors that are performing number crunching it's not clear.. it is expected that they get significantly rearranged for the purpose of specialization.. which says one can't see in to them because it will be a hardware-specific thing that is who knows what.. at the same time, one wishes to debug, so one wants a verbatim view of processors corresponding to the original source-specified processors, and one wants a view of datums moving among these processors.Thinking perhaps have some kind of debugging option that does a non-optimized specialization that allows each processor-shape specified in the source code to be see-able in a visualization of a processor created from that source. And, to be able to tag datums flowing among those processors and get some kind of visualization of the interleaving of data flows and whatnot, for seeing unexpected need for atomicities and so forth..-- Seeing maybe some kind of unique ID given to each syntactic entity.. there will be many Visualizers for a given srcHolder, for example.. have to be able to match up something.. what was I thinking about while driving?-- This syntax is not interpreted form..-- Seeing syntactic sub-entities like the Tensor index columns being used in ways like letting a variable stand for either a raised or lowered abstract index, which gets picked off from somewhere else and landed in there.-- One biggie is re-use.. the thing about being able -- Seeing have a symbol stand for an entire worksheet.. for example, construct this worksheet that has multiple processors on it, some srcManipulators, and creator spitting out a processor created from the manipulated source, and so forth.. that whole thing has some input ports and some output ports. A custom symbol is created, and the inputs on the symbol attached to the inputs on the worksheet, the outputs on the symbol attached to outputs on the worksheet.. then that symbol can be placed on some other worksheet..Let's see.. can such a symbol be placed directly into EQNLang source? Question here is whether have different kinds of source for doing things in workSpaces than have for equation manipulation, for “normal” code.. “normal” code would be something can do a from-into substitution on and get SOURCE CODE as the into.. now, talking about getting actual, already created and running processors as the into.. the first is a manipulation of data inside a srcHolder, the second is modifying the namespace of a workSheet and invoking OS commands to translate, create, and place..So, have one unified language where all that is mix and match, or make a separate architectural language?Has implications for the syntax graph, and how re-write happens, and so forth-- The syntax graph is going to be close to the surface.. it's close to the visual elements, and not yet in the form that would make sense for executing.. it's a raw form that is expressly for entering correct grammar and visualizing it..Worry about semantics of the syntax later.. when do, will probably end up modifying the syntax approach quite a bit, but for now, just concentrate on getting the syntax entered, and entered in a way that have the flexibility to define matchable and substitutable patterns.. -- Want the := definitions to have a simple mapping to from-intos.. want to be able to enter from-intos directly.. worry about making them pretty later.. for now, just make entering from-intos display straight lines, maybe in a grayed or a light color or something, between the from-location and the into-location.-- Starting to see this.. have things that specify the node, call it node Foo, that corresponds to a custom-notation.. have things that specify the grammar for what other nodes can be added in which parts of the Foo node (children, parent if have special non-symmetric parent reqts).. have things that specify the GUI gestures to indicate adding a Foo node.. have things that say how to break a Foo node into a GraphicalElement representation of it.-- Have a tool that can grab a vector graphic into, then drag boxes to locations around that graphic. If a compound syntactic entity is what are building in the tool, then define the sub-components and state the grammar for which sub-components can go where. The sub-components are also built in the same tool.-- the tool will generate a from pattern, to which one assembles an into pattern and connects parts of the from to parts of the into. This tool will spit out all the things needed to give to the Visualizer, the Modifier, the Display, and the re-writer (The Modifier == Editor before) the Modifier gets the piece that constructs an actual syntax-node(s) in response to a GUI gesture.. so that's where the actual syntax node that goes into the Model is defined. The Model is passive so it doesn't get anything generated by this tool. The re-writer gets a separate syntax-tree of the from-into pattern..-- Thinking the from-into patterns have to be visible in the srcHolders as well.. not sure what want visualization to be.. when browsing, will be at some level of the code, and want to see the from-into for a particular symbol.. DrawingShort list of what want the syntax graph to do (not even sure it's going to be a graph, or a tree..)-- Syntactic entities ==> a processor is a syntactic entity-- Kinds of syntactic things:-- -- Variable:-- -- -- Defined by “:=”, where it defines a variable in an equation.. such a variable acts like the “from” in a from-into pattern-- -- -- Used inside a “:=” as the equivalent of an arrow in a from-into pattern-- -- -- What about “flat” variables.. a srcHolder level thing.. works the same as #include <came back and added this after the below discussion>-- -- -- ?Other kinds? The first kind is a semantic variable.. it has computational meaning, is used during searches for re-writes the second kind has only internal-to-syntax meaning.. it's just a different form of expressing an arrow.. such variables are never affected during re-write.. they don't take place in the search for re-writes and have no bearing on which things get re-written.. they are only used during the mechanics of performing the re-write after a re-write has been chosen.. the second kind of variable has different rules for how it is used..What other kinds might there be? Perhaps ones that are simple “short-hand” in the srcHolder itself? Let's see.. so far the two kinds are distinguished by whichprocessor (which animator) recognizes the variable as something other than “random” data .. The first kind of variable is recognized by the re-write scheduler. The second kind is recognized by the processor that gets scheduled to perform the re-write operation. A third kind may be a variable that is recognized by the srcHolder as something that is outside the system of re-writes. Maybe even variables that the Modifier and Visualizer recognize that everything else treats as verbatim. Okay, so a concept here of one kind of variable for each kind of processor that touches the source code. There is one kind of semantic for each kind of processor that touches the source code.. that processor touching the source code is the animator for that semantic. So, how about a further kind of variable that represents a processor, like a memory processor, like a storage location.. such variables would have some re-write semantic (affect scheduling of re-writes for example).. such variables would also have an execution-model semantic for the primitives execution-model. This would translate directly to a hardware-processor interface semantic (ISA semantic), such as a main-memory location.-- -- -- So, leave room in the syntax for additional kinds of variable-- -- -- So, a variable in the syntax is a character string, with a variable type, and that variable type has a font assigned to it inside the visualizer-- -- A from-into pattern is a syntactic thing.. but it's a different kind.. it's communicating something to the re-write processor that the re-write processor uses to find matches.. A from-into pattern is NOT part of a processor-specification, but rather defines semantics for patterns that might appear in a processor-specification. A from-into pattern does not state the use of processors, rather it specifies the behavior of processors that might be used. It specifies what processors invoked elsewhere do. IE, a from-into is like a procedure definition, where as an invocation of a “from” is like an invocation of a procedure.-- -- A from-into pattern may have inside it invocations of “from” patterns..So, have specification of from-into and have invocation of “from”.. Two different things..-- -- A “:=” is a shorthand for specifying a simple kind of from-into pattern.. “:=” is specified by a from-into that constructs a from-into-- -- have no “=” sign.. have assignment to a location “<-”, have communication between processors <placing syntactic-entity in in-box postion of another syntactic-entity>, have specification of a from-into pattern “:=”, have matching to property pattern “==” “=<” “>=” “!=” “<” “>”.. the kind of assignment is determined by the position in the syntax-graph and is indicated by a property attached to the syntax-node. The property states which kind of assignment. May have other kinds of assignment that indicate semantics of additional kinds of variables relative to which of the kinds of semantic the variable is recognized by. IE, each kind of processor has its correlated kind of semantic that that processor is the animator for. Each of those has its own kind of assignment. That kind of assignment states the behavior of the variable when the variable is recognized by the kind of animator that recognizes it. The different kinds of variable are kept separate by having a property attached to the variable node that says which kind of variable that node is. The grammar enforcement parts will ensure that a variable of a certain property only shows up in the syntax graph in places that it is grammatically allowed.-- -- Q: how to make sure that have enough flexibility in the “custom”ness of the language?In use, what kind of customness is wanted? Want to be able to specify processors that operate on source code as data.. if wanted to be more pure, would allow easy inter-mix of processing source as data then using the processed source to create processors that behave according to the processed data.. which in turn can dynamically decide if they want to manipulate source further, then that manipulated source turned into a processor, and so on.. But, in practice, turns out don't really use that ability very often.. may be cool, but the practical implications in implementation and speed of processing have more impact on the usefulness of the language than the presence of that ability has. In practice, as far as I can tell so far, all the cases where perform src manipulation, it's acceptable to take the time to do a translation step after the manipulation, to translate the manipulated source into some native format for the hardware. Then create the processor that behaves according to the manipulated source from the translated-to-native form of the source.Just need some nice syntax to indicate this.. in Lambda, had a deceptively simple syntax.. deceptive because it looked the same as every other kind of code.. but in practice, there is a great difference between places in code where code is actually dynamically modified then the modified form used to create a processor vs places in code where the “form” of manipulation is equivalent to a statically deducible re-write.. the “match” statement in OCaml, for example, looks like a src manipulation, but in practice, it is only ever used as a static re-write.. Must have call-by-name to actually perform src manipulation that then gets turned into a processor. And OCaml doesn't have it.. that's part of the evidence that such a feature in the language is rarely used in practice.. so EQNLang does actually have the equivalent of call-by-name's dynamic code-modification.. but it requires performing a translation step on the modified code, and it requires explicitly saying “I'm going to dynamically modify source then use the modified source to create a processor”.. The feature has the same form and one must recognize the implications of the use in a call-by-name language.. in contrast this feature has an explicitly different form in EQNLang.. in fact, EQNLang can perform OS calls, so the dynamically-modified source could even cause the modification of the workSpace to cause a brand-new translate-create step to be dynamically inserted.. the dynamic insertion of the translate-create is performed by a processor whose source was itself dynamically modified.. so there is full theoretical flexibility here.. only a loss of “sneaky” syntax that hides it.. At least I know which quarter the attack on the missingness of the call-by-name sneaky use will come.. Mainly Haskell camp, I believe.DrawingShort list of what want the syntax graph to do (not even sure it's going to be a graph, or a tree..)-- Syntactic entities ==> a processor is a syntactic entity-- Kinds of syntactic things:-- -- Variable:-- -- -- Defined by “:=”, where it defines a variable in an equation.. such a variable acts like the “from” in a from-into pattern-- -- -- Used inside a “:=” as the equivalent of an arrow in a from-into pattern-- -- -- Leave room for variables that are defined with meaning for other animators than those two..-- -- Property.. list of them attached to every syntactic node.. each property has a property-of-properties property itself.. for example, a property is “integer data-type” and property-of-properties of the node holding “integer” is “data-type-property”.. so the property is integer, and the set-of-properties that property belongs to is “data-type” properties-set.. and the set that the “data-type” properties-set belongs to is “interface-contract” properties-of-properties-set.. and so forth..By having flexible properties like this.. for each property, include the “from” pattern that has to be matched for something to qualify as having the property, and include any “from-into” patterns that can be used to re-write things that match the property.. or, actually, state which from-into patterns are at least partially satisfied by a thing that has the property.. that makes a general system for deriving properties.. and the equivalent of type-checking will be property derivation, and search among the intos of all the froms that satisfy for the into that has the properties required by a position in the syntax-graph.The property checking system might be turn-offable when performing a translation of manipulated source in a live system where a person is waiting for the translation to complete.. rather, include facilities to back-track from a problem that occurs due to incorrect properties.. back-track back to the source manipulator(s) that code came out of that caused the property mis-match..This would imply that src manipulation must perform searches itself.. for example, cause src manipulators to perform re-writes themselves, instead of having the normal translator do it? Something like that.. will have to see performance issues and whatnot when it gets used..What really want is for all this machinery of re-write animator, of thing that processes properties-sets, of existence of syntax-graph, to all be specifiable from within the language itself.. want the language to be able to create itself within itself, and extend itself, and re-shape it's nature, from itself without defining an entirely new system, but rather modifying the one the modifications are stated in terms of.IE, want to be able to state modifications of the terms-of processor the modifications are stated in terms of.Maybe that will be my next language.. these are much higher than the basic processor definition, or a Turing machine, or a lambda.. what want is a higher language that has nice facilities for people and good search primitives that can specify modifications of itself in terms of itself. To the point that the language is completely modifyable in every aspect, and the higher facilities like property-checking to derive which into fits the interfaces, or facilities to state the existence of such facilities as themselves are modifiable using facilities that have already been defined..You know, thinking will need several levels to do this.. such modification will require modifications on multiple levels.. for example, start with an implementation of the basic processor definition.. then use that processor definition to specify higher facilities like explicitly linking name-spaces and searching them and whatnot..Lost it here.. too far out in na-na land..DrawingShort list of what want the syntax graph to do (not even sure it's going to be a graph, or a tree..)Kinds of syntactic things:-- Variable:-- -- Defined by “:=”, where it defines a variable in an equation.. such a variable acts like the “from” in a from-into pattern-- -- Used inside a “:=” as the equivalent of an arrow in a from-into pattern-- -- Leave room for variables that are defined with meaning for other animators than those two..-- Property.. list of them attached to every syntactic node.. each property has a property-of-properties property itself.. Have a src manipulator defined that takes a syntax-graph and uses the properties to derive what properties have to be added to each node in order for them all to be consistent. After that, the re-write src manipulator can be turned loose.. when this src manipulator has several “from-into” patterns, all of whose “from” match, it will choose an into that has properties that match the needed properties. If none exist, it will try to generate a from-into that has an into that satisfies the properties needed.. requires that generators are reachable from the programSpace that are capable of generating such from-into pattern.At first, thinking programmer makes all properties explicit.. or, maybe the srcManipulator responsible for deriving them all simply presents choices to the programmer and makes them pick.. the human does the NP-complete part.-- entity-root.. this kind of node is a processor.-- -- consumableIt has input-links, and replaces itself with a datum. The “output” is the replacement part.. the entity is consumed and in its place appears a re-written form or a datum.. whatever it gets replaced with is the input to the parent of the consumable entity-root.A consumable entity-root has children-spots, each of which has properties attached that indicate the properties a node that goes in that child position must have (IE, the properties attached to a child-link state the properties that the consumable-entity-root that gets linked-to must replace itself with).. this is equivalent to contracts, I believe, in some sense at least, don't really know what contracts are formally.. but idea here is that the link says what input requires and the linked-to root says what output is generated and those have to match up, according to property-matching rules.. have a property-system, which is a src manipulator, that enforces this. The property-system might also be part of the re-write, and direct which “into” is chosen.An entity-root can be either derived or primitive. If primitive it states the properties of what it replaces itself with. If derived (custom? what name?) then it turns into one of whatever the “into” nodes turn into from among the available “from-into” patterns whose from's match the syntactic-entity. (In this case, the property-system will have to interact with the re-writer, which is actually performing computation.. re-writes are semantic computation steps).-- -- persistent-across-inputs.An entity-root can alternatively represent a processor that persists across inputs. A src manipulator would be an entity-root like this. Such syntactic-entities may have both input-links and output-links. The two kinds of links would be visualized differently, and would have different grammar. An output-link could then be connected to the input-link of some other persistent-entity-root..-- -- Notice that a persistent-across-inputs entity-root can only be connected to the ports of the same kind of entity-root.Likewise, consumable syntactic-entities can only appear “inside” persistent-across-inputs syntactic entities. The “inside” portion of an input port of a persistent connects to an input-link of a consumable.. at some point, a consumable must be parented by the “inside” portion of an output-port.Visualize it thusly.. the persistent entities are there across inputs.. an input comes along, from outside the OSInstance or from another persistent.. that input passes through the port to the inside of the persistent entity, and goes into the input of a consumable.. a chain-reaction of consumptions occurs, ending in the final consumable turning into a datum that hits the inside of an output-port. That causes the datum to pass through and travel between persistents.This is the difference between an imperative program and “math”.. math is thought of as only being consumables.. whereas imperative has the notion of persistent -- the persistent storage location (which is a memory processor).Can unify the two by introducing co-recursive thing that continually re-writes back-and-forth.. that's a storage location.. so each consumption causes the creation of another consumable, and that in turn causes the creation of another, and so forth, back and forth.. That same technique can be used to re-create a consumable that waits for inputs.. provide some do-nothing input from the co-recursive twin. But make it so that any input to the input-port will pre-empt the do-nothing input from the co. Could even make receiving an input keep that input around until it gets a pair, when multiple inputs are needed as a set.. or, to be analog of physics, would need to do something a bit more exotic to get the schedulings to all be consistent with observation.-- entity sub-node-- -- The index-column in Tensor notation is an entity sub-node.. such sub-nodes have properties attached, just like everything else.Hmmm.. is a “:=” variable simply an entity-root? Let's see.. one-to-one with a “from” on the left-hand-side.. and any “use” gets replaced by the right-hand-side. So, question: is syntactic-entity one-to-one with the “from” of a from-into pattern?Oh boy.. well, how about when have an expression involving many things, and some sub-set matches a “from” and gets pulled out and the remaining portions act as inputs that get shunted into the “into”..?Okay, whatever the answer, think at point of being able to start making some definite stakes in the ground of defining syntax-graph node..What a syntax-graph node is is a collection of properties.. the only thing is that are pre-defining the set-of-properties-es. For example “entity-root” is... drumroll.. a property. There is a processor in the system that expects that property-type to always be present, so instead of putting it into a linked list, give a fixed position to this property-type. The processors that care about this property-type are: grammar thing in the Display, the visualizer, and the Modifier.. plus the re-writer.So, syntax-graph node-type, with type-specific sub-typesIf an entity-root, then need either primitive or custom (derived?), and need name of entityEach entity-name may have other properties required: Each entity-name has a specific number of children inputs (when these input-links are null, they are visualized as boxes)each child-input has property-list that must be matched by whatever goes thereEach entity-root has property-list of properties of what it replaces itself with (?can be filled in during re-write? Progr interaction issue, I guess)-- thinking the properties checking system not needed.. because the grammar doesn't allow the construction of a syntax graph that would violate.. Q: is such a construction-based approach too limited?How about, first crack at EQNLang has no properties system.. it relies only on the construction-grammar to ensure input-required matches output-produced properties..So, have a link in every syntax-graph node that is the head of a linked-list of properties.. even if don't use them for the equivalent of type-checking, want the stub for them there.. will use them probably on custom syntax nodes, pass them along to the Display maybe, then the Modifier.. will probably find lots of uses..DrawingDrawingSyntax-graph nodeDrawingpropertiesListHeadDrawingnodeTypeDrawingDrawingentityRootDrawingentitySubNodeDrawingentityLeafDrawingreWritableVarDrawingentityRoot is either consumable or persistentDrawingDrawingpropertyListElemDrawing<fieldName | type of thing goes in>Drawing<fieldName | valid values>Drawingconsumable entityRoot is either re-writable or primitiveDrawingconsumable, re-writable entityRoot is re-written by something that resolves eventually to something that has a property in the “type” property-set that matches one of the list of type-set properties allowed by the input-link the entityRoot is a child of.. IE type of entityRoot must resolve to a type accepted by input-linkDrawingYou know, the issue with data-structures vis a vis dynamicness is that select-from-property-set is expected to be there for particular sets in relation to the presence of choices from other sets.For example, “entity-root” is a selection-from-property-set.. when that selection from the “nodeType” set is present, then a selection from the “persistent” vs “consumable” set must also be present. A data-structure is an a-priori statement of such requirements. Thus, some data-strucs are a statement of the set of choices-from-property-sets that must appear together. Visualize: “myStruc1”: “type1 Var1” “type2 Var2” myStruc1 is the name of the set of choices-from-property-sets. type1 is the name of the set that a choice will be pulled from. Var1 is the name of the choice from the type1 set, Var2 is the name of the choice from the type2 set. The statement of the data struc itself is a pattern that states that a type1 choice and a type2 choice that are correlated are present. The name of the pattern is myStruc1. When a lot of strucs are defined, then when create a variable, and state that variable is of type “myStruc1” then are stating the variable has a property. The property is that the contents of the variable matches the myStruc1 pattern. The set of different strucs is a set of properties. This set never appears explicitly in a language, but it does appear in a compiler or interpreter for the language. This set is the set of all such patterns that have been defined. Each of these patterns has the data-struc property. “data-strucs” is the name of the set of these patterns. Each of these patterns in the data-struc set has the data-struc property. Each of these patterns with the data-struc property correlates (I guess pattern == consistent correlation) a number of choices. Each choice is from a particular other set. The pattern of sets the choices are made from is the data-struc pattern. The values chosen are the values of a particular datum. By that datum having the “myStruc1” property, the consistent correlation can be invoked to get that two choices exist in the datum, and that one choice is from the type1 set, and the other choice is from the type2 set.How this is all useful is that this whole thing can be made meta. One issue I've been having with defining the Java data structures is that the elements of the structure change depending upon the values placed in certain fields.This dynamic-ness can be gotten around during this a-priori design of the language, by just including several “carrier” data-strucs, and putting a different carrier in depending on the value in, say the “nodeType” field.But, what happens when customize? If want to allow customization to the point that new sets of properties or even new sets of sets of property-patterns, etc are allowed to be added to the language, then such a-priori definition of data-strucs is inconsistent.. don't see a way to allow such customization when using a-priori defined data-strucs.So, make the properties system dynamic.. instead of relying on positions in a data-struc, and defining the data-struc a-priori, make a more primitive thing that takes the pattern that defines a property, and that also takes a thing that says what to do with that property.. essentially, making more and more of what the compiler does be now after-the-fact customizable.. like plug-ins to the compiler, in a way. Making more of the compiler meta, in a way.. what is hard-coded in the compiler, am instead taking the patterns underlying that hard-coding and instead hard-coding the underlying patterns.. then making a spec that is animated by the new more primitive hard-coded.. that spec has derived behavior that matches the used-to-be-hard-coded. So, a much smaller set of behavior is hard-coded now, and more of the behavior is stated in terms of primitives that can be used in the language itself being compiled.That would be fun for a future version of the language..For now, think will stick with just including simple custom properties and their associated patterns.. will put the potential for them into the syntax-graph node data-struc pattern.. but won't really use that potential until much later, after have more hands-on, and more structure defined..Drawinga ResolvesTo field.. later, will allow this to remain empty when first add a node, and will have a system invoked by the Modifier, and by the Translator, that deduces what properties many of the nodes MUST resolve to.. will ask programmer for help when get stuck.DrawingnodeType is to indicate what fields will be in this particular version of a syntax-graph Node.. see discussion of properties..syntaxDataType is the type of syntactic-entity.. this is customizable.. this is used to match to type-of-link-to-is-acceptable.. in some node-types, have links to other nodes, and a list of acceptable syntaxDataTypes that can be linked-toTokenType is what kind of thing can be used to represent the node.. in this case, either a variable of type TensRep, or an input-box filled by some expression that resolves to a TensRep-- note, this is from way back, wasn't thought-out from implications point of view, just made from a “looking at the visual representation of code” point of view.. so it's a bit inconsistent as far as implementing a type-deduction system and a consistent grammar.. the properties are fudged together here.. has to be re-done according to what worked out below.DrawingWant a type that says what shape the syntax-node hasWant properties that describe the resolves-to of nodes that resolve(in other places, want to know what properties must be possessed by a node before it can be placed at the end of a particular link)DrawingShort example of an editing session:-] The person does the GUI gesture to add a new outer-product node. --> The Modifier receives this, translates it to an “add command node” command along with the position to add it (which the translator figures out by knowing where the insertion point is, or where the mouse is when the GUI gesture is made)--> This causes the node representing the command to be added to the syntax graph. The node's child-links are empty. The Modifier moves the insertion point to the first child.--> The Visualizer generates an update to the DisplayList. The update includes changing which link is the focus pt--> The Display paints the updated DisplayList-] The user sees the command-symbol appear where the insertion point was and sees empty boxes where each child is, with the box that is the first child blinking to indicate it has the insertion point.-] While the insertion point is blinking, the user starts typing a string. When done, they hit enter and the string is sent as a GUI gesture. --> The Modifier receives the “stringEnteredAtInsertionPoint” gesture. --> The GUI gesture translator deduces that the string is a name and makes the “add syntactic variable” command. If the user wants some other kind of variable, they can pre-face the name with an escape sequence or else use a mouse or menu gesture. For example, they could enter a memProcessor variable, or a TensAbsIndex var, etc--> The Modifier performs the command and adds a syntacticName node, with the string as the name, and moves the insertion point to the next child-link--> The Visualizer generates and update--> The Display paints the new DisplayList-] The person sees the string they typed appear as a syntactic-name node where the insertion point used to be and they see the new insertion point blinkingDrawingNote that “token” was denominating a text-string verbatim typed in by person using GUIDrawingTerms related to “Display”Using the term “Display” because Display seems to be the right word for the local window that paints DisplayLists. One will navigate within the Display and it may at times be visualizing one of the workSpaces or zoomed in on some other sub-set of the CTOSInstance.Thinking that perhaps have only one kind of Display that morphs itself as navigate.. The difference will be the GUI Gestures available.. for example, the pallette (toolbar) might change, the mouse-menus and other menus might change.. they might even change as the focus moves from one processor to another.. will have some kinds of command for workSpace, other kinds for custom-defined Space, others for myDataHolder..So.. seeing have only one kind of Display on the local machine, which then changes itself into specializations depending upon which processor in the CTOS Instance has the focus-token. Thinking that even when zoomed in and only looking at some deeply embedded processor, can still have the focus-token attached to an outer processor, and so the Display has the behavior-specialization for that outer processorOkay, so need the term Display, check. And need some way of saying what the Display behavior has been specialized to.. so, how about EQNLangSrcHolder Specialization, or EQNLangSrcHolder DisplaySpecialization. with “specialized Display” as a short-hand?DrawingDrawingDrawingHow one works with SyntaxWhat things will one do that the syntax tree must support?-- have the whole properties thing down.. properties are soft, define new sets of property sets and sets of those and so forth in customization code that is written when defining a new language. -- For EQNLang, have visual elements in the syntax graph.. a syntactic entity has an element for each logical element in the notation.. for example, when have pictures as the code, like the ones Gabe was drawing, the orientation in 3 dimensions has syntactic presence because it has semantic meaning, the orientation conveys pattern-information used in the “computation”. Which end the arrow is on, the linking of a swirl arrow to an upright one to indicate direction of rotation, the length of the arrow, maybe the thickness.. each visual cue is associated to a semantic infum. So, each visual cue has to have a corresponding syntactum in the arrow-syntactic-entity.So, put a stake in the ground: each visually information-carrying aspect has a corresponding syntactic node that is part of a syntactic unit.. yeah, “unit” is a better word than entity.Okay, getting close to capturing all the weirdness things..? Have italicization of some strings.. that's a visual cue.. the meaning correlated to that visual cue is kept in a syntactum. In this case, thinking the syntactum is a property node.. so, distinguishing a literal-relative-to-first-re-write name from a match-to-indicate-arrow-between-boxes-in-from-into name is done via a property node. So, such names will both be self-contained syntactic-units.. They will have a string with the visual shape of the name, and properties indicating, locally to the language, that one is a literal-in-pattern variable, the other is a use-to-match variable. So now, question coming, what distinguishes larger semantic roles, like role within re-write? IE, a variable is a match candidate, while a command implies a particular syntactic-unit shape, and implies a particular from-into pattern.. very different roles within re-write.. so, going to use just property-nodes, and have the language custom-stuff be the one to figure out that those are very different things?Yes.. why not. All have in syntax is one node correlated to each visual semantic meaning cue, and syntax-unit that groups a single semantic unit. Have property nodes, which are what distinguish the role within the language, and what determine the GUI rules of construction. And have structure nodes, which are what group syntactums together into a syntactic unit.And that, I think, is about it.. I think that's all that is needed. Okay, so just two kinds of syntax data-structure.. structural nodes and property nodes. Every structural node has a linked list of property nodes.. or maybe a hash or something.. linked list for now..Have two kinds of links.. semantic communication links, and structure-within-unit links.So, in a data-flow language like math, have links that represent the flow of data. In a step-based language, have links that represent transfer of animator between syntactic units (a semi-colon terminated Java statement would be one level of syntactic unit, within that might have a procedure-call syntactic unit and an assignment syntactic unit.. the operator precedence states the order of the animator traversing the links between syntactic units).In something like CaD, what would be the analog of the data-flow link and the animator-movement link? Don't remember it well enough at the moment..For CodeTime, say BaCTiL, have circuit-elements, have container-shape-definitions, have function-contents..DrawingWhat is Syntax(and what is Semantics)Finally, feel like getting close to closure on the whole syntax question: Here's the deal: When a human looks at a page of math, there are two things: shapes and spacial position. Each has a SEMANTIC meaning. The particular shape correlates to a pattern or some element of a pattern. The spatial position correlates to relationship within a pattern.. it indicates which portion of a pattern the shape-correlated belongs to.(it's all patterns..)So, syntax stands between visual on one side and semantic on the other. So, each visual cue that has semantic meaning must have a correlated syntactic element.The visual cues are shape features and spatial relationship. For shape features, look at the difference between a C and a G.. there is just the one little tick at the end. In Chinese, I believe, such little ticks don't merely separate two shapes, rather their presence or absence carries separate semantic meaning.. don't know the languages, but such a tick could, for example, indicate singular vs plural, or differentiate verb-meaning from noun-meaning, etc.. so particular shape matters.For spatial relationship, consider the shape “A”.. in the English human language, the position relative to other shapes from the alphabet set of shapes indicates sound: “CAT” the “A” has one sound, in “BAIT” the “A” has a different sound (or more precisely mouth shape, as the sound is really a large family of similar sounds, it is the mouth movement that is consistent)In, say, Java, consider “A =” where “A” has the semantic meaning that it is a memory processor that is sent the “write” command. whereas in “= A” the “A” has the semantic meaning that it is a memory processor that is sent, not the “write” but rather the “read” command. Just shifting the shape relative to the “=” shape gave it different semantic meaning.. and semantic is the observable behavior. “Semantic meaning” == observable behavior == state change (state change in the fundamental sense that an observation IS a state change).. so semantic meaning to a human is the steps the human will undertake.. “a semantic meaning” is correlated to “a human action” .. ahh, better, “a semantic meaning” is a semantic pattern, each part of which correlates to part of a human-action pattern. Yes, that is what semantic meaning is.. a pattern, each part of which correlates to part of a human-action pattern. A human animating the semantic pattern performs a correlated action-pattern, where each part of the action-pattern correlates to a corresponding part of the semantic-pattern.Okay, so semantics are patterns.. and human actions have pattern to them.. right.. correlation.. sweet.. finally, “semantics” has a clear meaning to me.. one that fits, is consistent, with absolutely everything else. I love these momentary flashes of seeing understanding absolutely everything.. all the patterns in all the world fit together, and pattern is what All is. and seeing that is a pattern that fits all the patterns.. self-recursive.. and that sweet, tight, perfect fit of all the patterns collapsing into this sweet minima of “energy” of patterns or whatever this feeling is.. niceGoing back to position in syntax.. have distinct “clusters” or complete patterns.. yes, that's it.. have a pattern that has several syntactic components.. the spatial position relative to each other indicates that the shapes belong to the same pattern, they are each a portion of one pattern.. Yes, that's what I've been chasing with this whole “syntactic entity” and “syntactic unit” thing.. PATTERN.. the collection of syntax the fills in one pattern.So notice, position can indicate meaning within several overlapping patterns at once.. consider “int A;” this appearing above some other appearance of A that is between the same level of curly braces indicates both places the shape “A” is seen the “A” is the name of the same memory processor. So, position relative to curly braces indicates name-space. At the same time, position relative to “int” indicates the creation operation and indicates the interface of the memory processor. So the same physical position of the “A” symbol has meaning in two different semantic patterns. Thus, the syntax must have a correlated syntax-pattern feature that includes the syntactic pattern correlated to that “A” shape in both semantic patterns.DrawingMore on What is SyntaxSummarizing:Visual pattern correlates to action pattern. The syntax pattern is a middle step between the two. The syntax pattern has a feature for each visual feature that affects the action pattern (when action pattern is animated).The syntax states exactly the visual pattern. The same visual pattern can correlate to very different action patterns for different languages. For example, in Pascal “A := B + 1” correlates to an action that is observably different than the same visual pattern in EQNLang (consider the variable properties.. int's in Pascal, but could be Tensors in EQNLang)The semantics states exactly the action pattern that the visual pattern is correlated to. Each language correlates a given visual pattern to different action patterns. Semantics is to action-pattern as syntax is to visual-pattern.So, the purpose of syntax is visual. The requirement of syntax is have a feature for every visual feature that can correlate to an action pattern feature.And that, in a nutshell, is syntax.So, can have a single universal set of syntax patterns that is capable of capturing every feature of correlation in a visual pattern.That, then is the task to accomplish.God this is great, after all that fear, and a couple weeks ago coming back to this, feeling completely inadequate and incapable, it feels great to finally have this nailed. To have a set of underlying patterns that are consistent with absolutely everything. Sweet. A small, simple set of patterns that fit with All. I love it. (something about that.. finding a small set of simple patterns that fit everything, that are CONSISTENT with everything.. something about that triggers this profound pleasure center for me.. recognizing when I have such a set of patterns underlying details I've been wading through.. that recognition triggers a pleasure pump in my brain.. THAT is a part of why I do this work.. and it's interesting that it's there.. have a feeling that many people don't have that trigger.. and those people won't choose to pursue finding such sets of patterns either.. Interesting from the standpoint of Inorganic Life.. what “should” they have in them.. what emotional mechanisms.. where “should” == I want the IL to match as high on some goal-pattern that I have as I can arrange things.. so “should” means that the “should”ed thing (action here) will move IL higher in the goal-measurement.. but not really clear on that goal pattern yet.. it scares me a bit looking there.. is it a power thing? I think so.. in much part.. a “father” thing also.. creating life (which has a power component).. yeah, and a name.. that seems to be lurking within me.. being the Archimedes of these times to the future.. I feel like that's a built-in emotional mechanism thing.. (also interesting in itself to IL) )Back to visual elements.. the visual elements-of-correlation:-- shapes-- pieces belonging to a single pattern-- multiple levels of patterns (full pattern being element of another pattern.. strictly visually)-- can have a shape be a piece of one pattern-- can have a pattern that has a given shape as part of it in turn be itself a piece of another pattern-- can have a single shape in single spot be a piece of multiple patterns (namespace pattern as well as command pattern)-- visual position of shape indicates:-- -- inclusion as piece of pattern (ie, this shape is in this pattern over here instead of that pattern over there)-- -- position within hierarchy of patterns, via inclusion directly within one particular pattern that is itself in the hierarchy-- -- visual position can indicate a single shape's direct inclusion in more than one pattern at the same timeFor example, consider a page of math. At the top a variable is defined. Down below a variable of the same name is used. The use of the variable in that position places the variable both in a namespace pattern, which is how the semantic meaning of the variable is determined, and at the same time places the variable in the usage pattern. The syntax should capture the inclusion of the use in both of those patterns. One way is to have the syntax map the positions of each shape relative to the other shapes. The other way is to use implications from the semantics of the language to determine any links such as the namespace link. Looks like going to do this option.. use the GUIToCommandTranslator to figure out all the different syntactic patterns to associate a given syntacticElement to.So, in the syntax data structure, make a link be the embodiment of visual inclusion. Make a link to each pattern-root that includes a particular syntactic element as a direct member of the pattern. A link is the equivalent of visual inclusion.Let's see.. want an inclusion link for entire sub-pattern, so that's a link from the syntacticPatternRoot? Want an inclusion link from each and every shape-containing syntactic element?Seeing kinds of things that work across languages.. -- have node that has a shape directly in it.. -- have a node that is only a carrier and organizing point for other nodes (TensorIndexColumn for example).. -- have a node that is the root of a single pattern.. -- have a node that represents interaction between patterns? IE, transfer of animator in a sequential language, or transfer of data in a data-flow language (like math notation).. must include this.. some languages have visual elements that directly correspond to interaction (like BaCTiL for example, and other large grain data flow languages). Some languages use physical location on page to represent this interaction, other languages have explicit visual shapes that indicate this interaction. So, make it an interaction syntactic element, without implying the nature of that interaction.. for example, consider Linda or Vitria, which would represent channels with syntax, and have syntax that indicates interaction with such a channel.. in this case the interaction is posting a match pattern and accepting a match back, or sending a message.. so could have a visual representation of send a message, which is an interaction, so make an interaction an explicit syntactic element type. Or, want to play it safe and just make interaction be indicated as a property.. so use a standard syntactic element as the link between patterns, and indicate that it is a link as a property with the propName == “link”, and the propValue == <the link value>..? Which way want to start? Start with the more-work method (everything is a syntactic element), or have a little bit of built-in specialization (multiple Java types of syntactic element)Okay, quicker if I just start with a single Java type: syntacticElement.. then make links be a property-value, and make interaction be a property-value, and so forth..Here's what I'm seeing: interaction-links have “dataSentTo” or “dataReceivedFrom” property name, with pointer to receiving-port or syntacticPatternRoot syntaxElements, where receivingPort and sytacticPatternRoot are themselves properties attached to the target syntactic elements.The properties will be handled by big switch statements.. can even make the propertyNames enums, one enum set for each language.So, here we go..DrawingSyntax Graph for a Simple CaseHave two kinds of structural syntax nodes: elements and linksEach kind of structural node has a list of properties attached.The elements have a list of links, in addition to the list of propertiesThe links have a pointer to an element plus a pointer to more links in the list, in addition to a list of propertiesA property node has a property name, a value from that property set, and a pointer to more propertiesRed round-cornered boxes are elements, blue round-cornered boxes are links, green rounded boxes are property nodes, and arrows are pointers among nodesIn practice, it turns out to be more convenient to inter-mix a bit of semantic information with the syntax information. The structure of the graph remains essentially entirely syntactic, but some of the properties added have a mixed semantic and syntactic role. For example, type information is partly syntax when used to choose the visual shape, and partly semantic. Type properties are included in the syntaxGraph, in part, because they are used in the grammar. The grammar is implemented cooperatively by the Visualizer, Modifier and Display, which all work together to only allow building a syntax graph that is consistent with all grammar constraints.In additions, the syntax information is a bit removed from a strict visual correlation.. the Visualizer acts as a translator between the syntaxGraph and the pure syntax (which is one-to-one with visual). The syntaxGraph is thus a bit closer to semantics.For example, the syntax-graph states that an element is a command, and states the name of the command. But it is the Visualizer that determines which shape will be used to draw that command. So shape information does not appear in the syntax graph, only in the DisplayList.DrawingA + BDrawingpropertiesDrawinglinksDrawingpropertyName: ElementTypeDrawingpropertyValue: VariableDrawingmorePropertiesDrawingpropertyName: VariableTypeDrawingpropertyValue: MemProcessorDrawingmorePropertiesDrawingDrawingDrawingDrawingpropertiesDrawinglinksDrawingpropertyName: ElementTypeDrawingpropertyValue: CommandDrawingmorePropertiesDrawingpropertyName: CommandIDDrawingpropertyValue: IDOfPlusDrawingmorePropertiesDrawingDrawingDrawingDrawingpropertyName: VariableIDDrawingpropertyValue: IDOfVarADrawingmorePropertiesDrawingDrawingDrawingDrawingDrawingDrawingDrawingDrawingDrawingpropertiesDrawingelementGroupDrawingDrawingpropertyName: LinkTypeDrawingpropertyValue: dataCommDrawingmorePropertiesDrawingGroupDrawingpropertyName: DataTypeDrawingpropertyValue: inheritedDrawingmorePropertiesDrawingDrawingDrawingDrawingDrawingpropertiesDrawingmoreLinksGroupDrawingDrawingpropertyName: LinkTypeDrawingpropertyValue: dataCommDrawingmorePropertiesDrawingGroupDrawingpropertyName: DataTypeDrawingpropertyValue: inheritedDrawingmorePropertiesDrawingDrawingDrawingmoreLinksDrawingDrawingelementDrawingpropertiesDrawinglinksDrawingpropertyName: ElementTypeDrawingpropertyValue: VariableDrawingmorePropertiesDrawingpropertyName: VariableTypeDrawingpropertyValue: MemProcessorDrawingmorePropertiesDrawingDrawingpropertyName: VariableIDDrawingpropertyValue: IDOfVarBDrawingmorePropertiesDrawingDrawingDrawingDrawingDrawingDrawingDrawingDrawingNotice that variables are identified by an ID. The Visualizer keeps the visual representation of each variable. The Modifier receives data about the visual appearance of each variable from the Display (eg a string of the variable name). The data comes inside a GUIGesture sent from Display to Modifier. The Modifier must relay this information directly to the Visualizer. The Modifier does not keep this information, nor does the syntax graph hold any indication of the visual appearance of variables. Many variables are visually represented by strings, so the Visualizer would store such a string. The font of the variable, however, indicates properties of the variable. For example, a memProcessor has a different font than a level-below SyntacticVariable. Each kind of variable is rendered in a different font, with different effects. The font and effects are chosen by the Visualizer, and correlate with the properties of the variable. The properties are stored in the syntaxGraph.Likewise, the visual representation of a command is also kept inside the Visualizer.Notice as well that when implemented in Java, for example, all property names and all property values can be enumerated types. One complication is that some command names are custom and generated during entry of a syntax graph, and the variable IDs are all generated during entry of the syntax graph. Thus, in Java, propertyValue is likely to be an integer that is correlated to an enumerated value. The integer will be used in a switch statement. There will be a fixed number of propertyNames for EQNLang, so that will be an enumerated type.DrawingpropertyName: SyntacticStructureTypeDrawingpropertyValue: syntacticPatternRootDrawingmorePropertiesDrawingDrawingDrawingHierarchy (Dependencies) of PropertyNames and PropertyValues in EQNLangt.DrawingpropertyValue: NameDrawingpropertyName: TypeOfNamedDrawingpropertyValue: MemProcessorDrawingpropertyName: ElementTypeDrawingpropertyValue: CommandDrawingpropertyName: CommandIDDrawingpropertyValue: IDOfTheCmdDrawingpropertyName: NameIDDrawingpropertyValue: IDOfTheNameDrawingpropertyName: DataTypeDrawingpropertyValue: inheritedDrawingpropertyName: SyntacticStructureTypeDrawingpropertyValue: syntacticPatternRootDrawingDrawingDrawingDrawingDrawingDrawingDrawingpropertyValue: SyntacticLinkDrawingpropertyName: JavaClassDrawingpropertyValue: SyntacticElementDrawingpropertyValue: NameLinkDrawingpropertyName: LinkTypeDrawingpropertyValue: dataCommDrawingDrawingpropertyValue: StructureDrawingpropertyValue: ProcessorDrawingpropertyValue: SyntacticSearchDrawingpropertyValue: PatternDrawingpropertyValue: SyntacticDrawingTreat constants as mem processors. So, for example in custom Tensor notation, the index-column is a Structure ElementType, and so is the Tensor Index that goes into it. That Tensor Index has a link to whatever is seen at that point. It could be a name that stands for a processor that will be sent from somewhere else.. in this case it is a Name ElementType, with a dataComm link to whatever syntacticPattern sends the data. Sending data is sending a processor containing the data.Or, the Tensor Index could be a name that attaches to some other bit of syntax. This is the thing where have a complex expression and just assign a syntactic-level name as a short-hand for that expression. (What about syntax-embedded re-writes? This is what SyntacticSugar is in Scheme, and what a macro is..)Or, the Tensor Index could be a constant. In this case the element is a Processor. Will have probably a property for Processors, that can put in the syntax directly, that they are a constant-containing processor, and what the constant is.Pattern I'm seeing as a from-into pattern.. it's not a command, because command is the name attached to that pattern.. so need a way to say “this is the pattern itself, the thing attached to the command-name” (where attached means correlated-to)Drawingthinking “Syntactic” Link is for syntactic-name and for syntax-level rewrites (need some way of getting at the concept of srcManipulators that are embedded.. ie, some code specifies a re-write to other code that takes place before the other code reaches the translator. Some sort of notion of “when” the re-writes happen.. the re-write is turned off for the code that specifies the re-write to be performed on other code.. Same notion as in the different kinds of variables.. one kind is used to match, to specify the from-into pattern.. the second kind of variable, sitting right next to it, is not used when detecting matches. There could be two of those also, but they are not looked at by the match-detector. However, after the match detector is done, have a from-into pattern that has those second kind of variable in it.. NOW those become active, when the re-writer kicks in. The re-writer will see those and perform substitutions. So, the distinction is which processor treats them as semantic info vs flat data. This is what “*-time” means, the * is the name of the processor that performs the manipulations. “Edit-time” is the editor, “run-time” is the animator, “install-time” is the install-processor. So seeing some syntactic-notions meaning “before normal re-writer”, this is the macro-notion.. something that operates on the source code as data devoid of semantic meaning. Whereas the re-writer treats the source as does have semantic meaning.. that's the distinction between macro-rewrite and “normal” re-writeDrawingDrawingDrawingDrawingpropertyValue: syntacticStructureDrawingDrawing? not sure what to do here ?Drawing? not sure what to do here ?DrawingDrawingDrawingDrawingDrawingDrawingpropertyValue: SyntaxGraphDrawingpropertyValue: ?Link?DrawingThe SyntacticStructureType is for partitioning into whole syntacticPatterns.. it is used to find all the structure elements that go with each root element.This is used when positioning shapes and deciding the scaling. All shapes in a single syntactic pattern will get the same scaling.DrawingGraphic -DrawingDrawingExternalTunnellerDrawingDrawingIntegrateEqnManipulatorDrawingDrawingmoreElemsDrawingmoreElemsDrawingmoreElems \ No newline at end of file diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Fb_10___Custom_TensRep_notation.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Fb_10___Custom_TensRep_notation.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,12967 +0,0 @@ - - - - - - image/svg+xml - - - - - - - - - - - To Add on This Page - Tensor outer-product custom code that takes the syntax sub-tree and produces the from-into tree - Tensor reduction custom code - Thing where Tensor outer-product is applied, then reductions are searched for and applied - The syntax tree that gets built by the GUI commands for custom notation - The visual definition that defines the custom syntax - The visual definition of what gets sent to the GUI to tell it how to handle custom notation - The visual definition of: - -- there's what the editor does -- define the nodes of the syntax tree that get added, and define - what command comes from the GUI to cause each node (look at issues about grammar, - about how editor tells GUI when invalid commands have come in, or an invalid order, like - trying to move on before finished, or something... maybe just visual queues of what's not - right in the syntax tree are sent to the GUI) - -- there's what the GUI displays -- draw the vector graphic - -- there's the visual-elements structure.. have boxes for each column of tensor indexes, and have - that composed of an upper and a lower, and indicate can only have either an upper or a - lower.. so, draw the boxes.. state tokenType allowed inside each box -- tokenType is more - than just visual, a tokenType exists for each type of thing can be displayed.. - -- note that there's one tokenType, italic, for a variable that is an input, and a different tokenType - - complete, as a variable.. whereas the italic-input-variable will be replaced (an italic-input- - - -- there is a tokenType for integers, a tokenType for dimension that can be placed in the index - position of a tensor, a tokenType for variable, a tokenType for input, a tokenType can be - - used, along with restrictions on the characters (ie, one can define a tokenType that can only - have the integers from 1 to 50).. or can define a tokenType that one must query a processor, - during evaluation of a grammatic sentence, to find out what the allowed character-values are - (for example, ask the particular TensRep what is its working dimension, or attach the - dimension as a value to the tensor-phrase, and make the tokenType only take values from 1 - to that dimension --> this would be compatible with the way Gabe wants to use Tensors for - his electron-states thing, where each tensor has a different dimensionality == number of - allowed states or something like that. - - # -- there is stuff modifies the GUI -- have to tell GUI each gesture, and what to send to editor for - each gesture - # -- then have what editor does with thing it gets from the GUI --> the syntax-tree element it adds - and - -- where editor adds that syntax-tree node (deal with insertion point) - -- what the visualizer does with the syntax tree created by editor --> what the visualizer sends to - the GUI - -- what the GUI presents visually for each thing sent by the visualizer - # Finally, have the sequence of events, starting with GUI gestures, that builds an expression in a - custom syntax, and ending with the sub-tree being sent to the command-generator, a new - syntax-tree being generated and added to the programSpace, and the name of that newly - generated command being sent back to the editor and inserted in place of the original - - - - - - - - - - - nodeType: commandRoot - commandName: TensRepOuterProd - IndexedTensRep - Defining Custom - Tensor Notation - - - - - - - - - - IndexedTensRep - - - - - - - - - - LH - RH - - - - - commandPatternName: generate - resolvesTo: IndexedTensRep - - - - - - - - - - nodeType: boxPhrase - TensorIndex - - - - - - - - - - TensorIndex - - - - - - - - - - Index1 - IndexN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . - TensRep - - - - - - - - - - TheTensRep - - - - - - - - - - - - - - - - - name. Then use the standard GUI gesture to - - - concatenated to the names. - Both AbsTens and TensRep use the same - TensorIndex - syntaxDataType: IndexedTensRep - A child is added via a GUI gesture, then a name for it - is entered. The arrow and the box it points to are - automatically popped up. - Each child box is labelled with a syntaxDataType. A - drop-down list is available that has all the known - syntaxDataTypes. It is important to remember that - a syntaxDataType is not a data type, and doesn't - define a data type. However, each syntaxDataType - is named the same as a corresponding data type. - The syntaxDataType appears in the syntax tree in - the position that a variable of that data type - appears or a command that resolves to that data - type appears. - So, the LH child could be, for example, another - TensRepOuterProd command OR an - IndexedTensRep variablePhrase, both of which are - syntaxDataTypes - langType is where the language-type of the phrase is - stated. This node defines what something of the - - The nodeType, langType, commandName, - commandPatternName, and produces are all standard - - are part of the OS Interface standard. - A GUI gesture is used to pop into existence a - - in the box, and a drop down list is available with - the standard node types, accessible via key - - - of a web page. - The node type determines the other fields in the box. - Those also have drop-down lists available - The boxes are not seen during use of the custom notation. - They are only seen while defining the syntax tree elements - that the editor will create in response to commands coming - from the GUI. - The GUI actions described in annotations here are actions - that happen during the syntax-tree element definitions. - Other GUI actions will happen when creating equations that - use the custom notation. - A boxPhrase consists of a box plus a number of operators - that take the box as input. The operators may be defined - to apply in any sequence or together as a collection or sub- - collections. However, the collection of operators must - only take the one box's contents as input. The data type - that the box's contents resolves to must be stated, and the - data type of the result of the entire collection of operators - must be stated. If not all operators have to be applied at - once, then the result of applying only a few is another - boxPhrase of the same type, but with fewer children. - This is a bit confusing because a boxPhrase is a syntax tree - node type, not a data type that flows between processors. - However, because of the requirement of partial evaluation - down to primitives before translation, one can act as - though a boxPhrase were a data type that flows between - processors. In fact, one can partially fill in a boxPhrase - and send that as an input. The boxPhrase must resolve, - once all children have been filled in and all the operators - have performed, to the data type of whatever box the - partially filled boxPhrase has been placed in. - For example, a pattern-function that takes an - IndexedTensRep may have an IndexedTensRep that has - empty positions (displayed in the equation as boxes) - placed in one of its input positions, as long as the pattern - fills in the empty positions, so that partial evaluation can - reduce all the way to primitives. - Also, boxPhrases can be nested, so that the result of applying - one subset of operators is the input to a further set of - operators. - During use, a box can have placed in its position a - boxPhrase, a commandRoot, a name (where a - name appears as a variable in an equation), or a - constant (of the box's type). - A boxPhrase can be placed in the position of a box - that takes such a boxPhrase. Doing so implies - that the operators of the phrase should not be - evaluated until after the boxPhrase is substituted - into the box's position, during partial evaluation. - A boxPhrase can also be placed inside a box whose - data type is what the boxPhrase results to. In this - case, the partial evaluator is free to perform the - operations of the phrase before or after replacing - the box with the phrase, whichever is most - convenient for the translator. - IndexedTensRep is actually an interesting example - of a boxPhrase. During use, the children-boxes - can have placed in their position variables, or - abstractIndexes, or integers from 1 to dimension. - The behavior is different depending on what is in - the position of each child box in the syntax tree. - If it is a variable, then there is no behavior, this is - just a symbol used in the definition of a function- - pattern to indicate matching between LHS and - RHS. Each match becomes an arrow between a - - If it is an integer, then the operation is a selection. - If it is an abstractIndex, then the syntax tree is - searched for matches. Any pair of matching - abstractIndexes are replaced by an operation on - the TensRep data structure that the box-of-the- - boxPhrase resolves to. This operation is - performed at run-time. It iterates from 1 to the - dimension of the pair of indexes. At each value - of iteration, both matching abstractIndexes are - replaced by the iteration value and a selection - with that pair of index values is performed. The - result of selection is added to a running sum of - the selection results. That sum is the final - answer. (note if not all the abstract indexes - match up in some pair, then the result will be a - TensRep that still has multiple indexes.) - resultDataType: TensRep - - IndexedTensRep - - - - - - - - - - nodeType: boxPhrase - TensorIndex - - - - - - - - - - TensorIndex - - - - - - - - - - Index1 - IndexN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . - TensRep - - - - - - - - - - TheTensRep - - - - - - - - - - - - - - - - syntaxDataType: IndexedTensRep - resultDataType: TensRep - - IndexedTensRep - Editor - commandFromGUI: addIndexedTensRep - The srcWindow in the GUI receives a gesture and sends the corresponding command to the editor in - the srcHolder attached to the srcWindow. - In the GUI, a user sees the outline of a srcHolder inside a programSpace. They perform a GUI gesture - on that srcHolder outline, which causes a srcWindow to pop up. The srcWindow displays the - contents of the srcHolder. - A srcWindow has a standard set of visualization commands that it understands. In addition, the - module that contains the custom syntax definition includes customization for the srcWindow. This - includes custom gestures with the editor command the gesture should cause to be sent to the editor, - as well as custom vector-graphics that the srcWindow should use as the display of particular visual- - element-names coming from the visualizer. - The visualizer handles placing every element relative to other elements. The visualizer understands the - language, so it knows about commands having children that appear as input-boxes in particular - positions relative to the command-symbol. - - structure that it is to draw at the relative position stated in the element. - The srcWindow handles translating the relative-positions stated in the visualization-hierarchy into pixel - positions within itself. It does the pan and zoom-level, as well as insertion-point, and focus. It also - recognizes custom gestures and sends the corresponding command to the editor. - - - srcWindow then displays. Thus, the srcWindow doesn't have to keep any state other than the visual- - hierarchy and how the current display maps onto that hierarchy. - However, the srcWindow does note which visual elements have focus and where the insertion point is, - because many GUI gestures have different behavior when the pointing-device is over a focused-on - visual element, or over the insertion-point. For example, right-clicking over a focused-on element - may bring up a different menu that right-click over non-focused-on. - The visualizer sends vector-graphics that are in relative-position to other visual elements, with an initial - size-multiplier. - So, the visualizer has the work of turning a syntax tree into a network of visual elements, each with an - offset relative to the others. It will do hierarchy.. so a given sub-tree will have a bounding box. - Then that bounding box is placed relative to its sibling bounding-boxes and visual-elements. That - group of siblings, in turn, gets a bounding box, and so on.. - This way, the visualizer only has to worry about placement of siblings relative to siblings, and can - ignore everything inside the boxes and everything outside the siblings' own bounding box.. - Except that increases and decreases in size of a given bounding box may have a ripple effect up the - chain. One strategy to prevent this is to alter the zoom-level of the bounding box so that everything - fits inside the same visual space. However, that may be confusing to look at.. I like the idea of - everything on a given level-of-hierarchy-of-bounding-boxes having the same zoom.. IE, if have a - foo-symbol in one box, and the same symbol in a sibling box, then they should display at the same - size. An alternative idea might be to leave extra space around all the elements when create a new - box, leaving room for changes.. and to let that space grow if things are deleted from a box. - The other thing is that the focus and selection-movement that the srcWindow does uses the bounding - boxes.. the arrow keys, for example, move the focus among bounding boxes of siblings. - Return causes the focus to jump into the focused-on bounding box. The focus jumps to whichever - bounding box inside had focus the last time focus was in there.. - Shift-return causes zooming-in to whatever bounding box contains the focused-on bounding box. - - - - - - - - - - nodeType: leaf - syntaxDataType: TensUpperIndex - - TokenType - TensDimension - TensAbsIndex - syntaxBaseDataType: TensIndex - commandFromGUI: addTensUpperIndex - - - - - - - - - - nodeType: leaf - syntaxDataType: TensLowerIndex - - TokenType - TensDimension - TensAbsIndex - syntaxBaseDataType: TensIndex - commandFromGUI: addTensLowerIndex - The syntaxBaseDataType is similar to syntactic sugar for - putting an OR list inside the child boxes of - IndexedTensRep - Also, remember that this specifies what the syntax tree will - look like, this is not an entry in the syntax tree itself. In - the actual syntax tree, there will be either an integer or a - letter in the node. Here, have to say that either of those is - okay to put in this position (TensDimension is a - TokenType that can have as its characters an integer from - 1 to the number of dimensions that the TensRep this - index is tied to has. - A TensRep is a data structure. So in the spec-of-the-syntax- - tree, there is no node for one, there is only a node that - - - - - - - - - - - nodeType: leaf - syntaxDataType: TensRepBox - - TokenType - TensRepVariable - BoxFilledByExpression - commandFromGUI: addValueNode - This notation here is what the programmer enters when - defining custom notation. Each box states an EMPTY - syntax node that gets added to the syntax tree in response - to the command coming from the GUI. The contents of - the box state the TYPE of things that can be placed in - the node by GUI gestures. - resolvesTo: TensRep - So, not getting these quite consistent yet.. need some work - to get the concepts right.. a little confused in these specs - so far on exactly what's what.. should clear up as do - details of trying to implement.. - - spec of a syntax-tree node that gets put in the spot where - a variable appears that stands for a TensRep data- - - to indicate that the syntax-tree node that the editor is to - create can have a box in this position that holds a big old - expression.. not clear yet on what exactly mean by - - - an inconsistency is that when filled by an expression, there is - a sub-tree that goes here that is the contents of the box. - Don't know yet what going to do about all this.. but it's - not a show stopper, just work that needs to be done. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GUI - Node: TensUpperIndex - Node: TensLowerIndex - TensIndexColumn - This specifies what the visualizer is to produce to - represent the stated node - This specifies new GUI gestures that the - srcWindow is to recognize, plus the command to - be sent to the editor as a result of one of the - gestures - This specifies a command received by the editor, - and the syntax tree node the editor creates from it. - The editor keeps track of the insertion point and - uses it to choose where to put the node or value. - When the editor receives this command, it will give an - error back to the GUI if the insertion point is in the - wrong place. - Also, after adding this node, the insertion point will - automatically be moved to this node. Thus, the next - - else a move-insertion-point followed by some other - command. - A token is a string of characters plus an indication of the - tokenType.. so, a function-parameter can have the exact - same characters as an expr-name, but they are displayed - differently and interpreted differently by the translator. - The function-parameter-token indicates that the tokenType - is function-parameter-tokenType, likewise the expr-name - comes in a token that indicates expr-name-tokenType - The function-parameter is displayed italic, while the expr- - name is displayed normal (normal is the default expr- - - - - serves better.. - Menu:Tensor, Entry: UpperIndex - - send: addTensUpperIndex - keySequence: /TensUpperIndex - Need: - 1) specification of what the visualizer is to do when it sees a given custom syntax tree node - 2) specification of what gestures the srcWindow is to recognize, and for each, what it is to - send to the srcHolder's editor. - 3) specification of each thing the editor can receive from the srcWindow, and what it is to - do to the syntax tree for each thing received - Note: there are standard commands sent from srcWindow to editor, such as - - So, when editing, might do the GUI gesture to add a new outer-product node. This causes - just the node representing the command itself to be added to the syntax tree, and the - insertion point moved to the first child of the node. - Visually, the user will see the command-symbol drawn where the insertion point was, and - see empty boxes where each child is, with the box that is the first child blinking to - indicate it has the insertion point. - Next, the user might enter a name that was defined elsewhere in the srcWindow - (srcHolder). The name will be typed in, and will appear in the rendering-font of - wherever the insertion point is. The user then does a gesture that moves the insertion - point. This causes the typed-in text to be sent as a token to the editor. - Palette: Tensor, Icon:<vector graphic> - The dashes indicate that it is a visual node but it doesn't display - Sequence of GUI interacting with - Editor and Visualizer - : - 1) User focuses on a srcWindow. - - --] This is done by using the ctrl+arrow keys, or by using the mouse then clicking. Focus is sent to the srcHolder, which - modifies the meta-data of the syntax-tree node that has the focus. The editor also looks for the sub-node that had the - insertion point most recently, and marks that node as having the insertion point. - - --] The visualizer notes the changes in the meta-data and sends a diff to the srcWindow. - - --] The srcWindow receives the diff and redraws the thing that has focus and the thing that has the insertion point. - - The user now sees the visual cue of where the focus and insertion point are. - 2) User enters zoom gestures and pan gestures to get to a section they want to modify - - --] focus and pan are completely handled by the srcWindow. The srcWindow receives a graph of visualization objects. - Each object states a size plus a position relative to other objects. These positions are all on a canonical grid. The - srcWindow keeps a zoom factor that is the ratio between canonical distances and screen-pixel distances. The - srcWindow also keeps a clip-window that is what gets painted up on the screen. Pan moves the clip-window around - and zoom changes the size, in canonical units, of the clip window. Then the clip window contents are multiplied by - the zoom factor to give pixel-unit sizes, and the result is drawn in the paint area of the srcWindow. - 3) User pulls down the Tensor palette and selects the icon for the outer-product command - - --] The GUI was told what command to send to the srcHolder for this particular icon when the Tensor Custom Notation - Package was loaded into the GUI. This command is sent to the srcHolder's editor. - - --] The editor was told what syntax-tree-node to add for this command when the Tensor Custom Notation Package was - loaded into the GUI. The editor adds this node, with all empty children and attribute fields. The node is placed - where the insertion point was and the insertion point is moved to the first child of the command node. - - --] The visualizer knows what visual elements to send as the visual representation of the newly added node. It was told - what visual elements to use by the Tensor Custom Notation Package. It sees the new node added by the editor and - generates a tree of visualization elements that gets rendered by the srcWindow. The user sees the command-symbol - - 4) The user then goes about moving the insertion point with arrow keys or mouse or other shortcut keys. At each point, - they do GUI gestures, to enter more nodes or to enter tokens (a name is a token). The user has GUI gestures available - to indicate the tokenType (pull-down list, icon, menu item, shortcut key, key-sequence). - At some point, all the children of the command-node have been filled in. At this point, the editor sends the command- - sub-tree to the programSpace, with the command to give it to the srcHolder-type's-custom-processor called - commandGeneratorProcessor. - That is, when a srcHolder is added to a programSpace, that srcHolder is asked for the name of the spec of any custom - processors the srcHolder wants the programSpace to make. The programSpace takes the specs and makes processors - from them, then hands back the name of each created processor (such a created processor can be a spawner). - The EQNLang srcHolders have the spec of a CommandGeneratorGenerator processor. This processor is created by the - programSpace, if it doesn't already exist (if there is another EQNLang srcHolder already in the programSpace, then - the commandGeneratorGenerator will already exist). Next, any custom notation packages that the newly added - srcHolder requires are loaded in. - The srcHolder for EQNLang is specialized especially for EQNLang. Part of the specialization is that each keeps a list of - all customization packages that are used by any of the nodes inside that srcHolder. When the srcHolder is added to a - programSpace, or when a new notation package is loaded into the srcWindow of a srcHolder, then some stuff - happens: The customization package includes the specs of custom-command-generators. These specs are sent by - the programSpace to the CommandGeneratorGenerator. The CommandGeneratorGenerator creates a new processor - out of each spec. Thus, the commandGeneratorGenerator knows about one commandGenerator for each kind of - custom-command node that is in any of the EQNLang srcHolders that are in the programSpace. - want this whole system to be generic. So, no matter what language, the srcHolder for that language is invited to give - specs to the programSpace and have the programSpace turn those into processors and give back the names of those - processors. Thus, the commandGeneratorGenerator is created via a generic mechanism. The programSpace has - nothing custom about it that was needed for the commandGeneratorGenerator. The programSpace only has the one - - srcHolder. - Now, when a new custom-command-node is finished, then its sub-tree is sent by the editor to the - commandGeneratorGenerator, which hands the tree off to the commandGenerator for that type of node. The - commandGenerator has all the information it needs within the sub-tree. It performs whatever its code specifies, - - tree. The new from-Into tree is given some randomly generated name. The name is sent back to the srcHolder that - sent the custom-command sub-tree. That srcHolder then removes the entry in the original custom-command sub-tree - - commandGenerator also hands the from-into tree to the programSpace to be added as a new library srcHolder. - Now that custom-command node is just like any other node that has the command-name of a from-into tree. - Tensor Outer Product - Command Generator - Need: to know how many indexes - What it does: takes two TensReps, produces a TensRep that has as many indices as the - sum of the indices of the two input TensReps. - The value of the outer product is: take any valid replacement of abstract indices with - integers, for all indices of both TensReps being multiplied. This will select a single - cell from each TensRep being multiplied. The product of those two cells is the - contents of the cell selected by the same substitution of abstract indices with integers - performed on the product TensRep. - So, a simple algorithm is to do a series of nested FOR loops. One FOR loop for each - index of each TensRep. The innermost loop's body takes the index-var values from - the outermost loops and uses them to access one cell of the left-most TensRep's - multi-set. It then takes the values of all the inner-most loops and uses that set to - access one cell of the right-most TensRep's multi-set. It multiplies the contents of - the two cells, then puts that value into the cell accessed by the values of all the - index-variables on the result TensRep. - Another way to state this is with invariants: - state the boundaries for each index-position, and state that the result-cell receives the - product of the two multiplied-TensRep cells: - R = A * B - 0 < j < 4 - 0 < i < 4 - 0 < k < 4 - 0 < l < 4 - 0 < m < 4 - 0 < n < 4 - l m - n - i - j - k - i - j - k - l m - n - Now, when a user enters a Tensor Outer Product, are restricting it to only take - TensReps as inputs, not AbsTens nor AbsTensFields nor TensRepFields. - There can be any number of indices, and in any order of raised and lowered. - Also, TensRep is a data structure that consists of a multi-set (a multi-set is a primitive - of the language), plus a vector indicating raised or lowered for each index-position - (ie, contravariant or covariant), plus the dimensionality of each index-position (in - general a TensRep can have a different dimensionality for each index-position. - Gabe uses this in his Tensor notation for energy states of bound electrons). - So, the command generator will examine the index-positions of each input to the outer- - product command. For example, the user enters: - R = A B + I - - - - - - - - - - - - - - - - - - - - - - - - - - - This needs to be translated into language primitives - -- each variable-name resolves to a TensRep or an IndexedTensRep - -- the outer-product command has to handle any combination of number and - dimensionality of indices of its two inputs. - -- The identity TensRep must have the same number of indices, the same raised- - lowered, and the same dimensionality as the result of the outer product. - - - -- If the number of indices of A and B are known at translation time, then a command - can be generated and its name put into the syntax tree as the from-into pattern to use - - The plugin looks at the data-structures it is handed and checks compatibility (rules - about number of indices, raised vs lowered and so on). It then performs a generic - outer product code that has one loop. A vector of index values, plus the two limits - for each, is kept. The loop increments the lowest index each time through. When - that lowest reaches the upper limit, it increments the index above it, then resets the - lowest to its starting value. When the one above it reaches its upper limit, it - increments the index above that then resets to starting value, and so on, until the - highest index gets incremented to its limit (limit checked against is one larger than - the largest value want the index to take). This generic code works for any arbitrary - number of indices and dimensionality of the input TensReps. However, good luck - - efficient if they can state somewhere the range of number-of-indices the input - TensReps can have, or state the most-likely number-of-indices (generate commands - for the most likely values and save this generic as a catch-all.. at run-time a switch - on the sizes jumps to one of the generated commands or to the generic). - -- would be nice if the invariants form could be used somehow in the generic catch-all - Sequence of Programmer Editing - Code Take 2 - 1) GUI gestures.. be they key strokes or mouse genstures or menu pull-downs or whatever.. these are used to construct a - syntax tree. - 2) As the tree is constructed, it is visualized.. the visualizer in the srcHolder sends a graph of displayObjects to the - srcWindow. - 3/ The srcWindow has a set of standard displayObjects that it understands. It has a standard graph data-struc that it - receives displayObjects in. It may receive either a baseGraph, or a diffGraph.. those names will change, but a - baseGraph replaces everything that used to be in the srcWindow. A diffGraph modifies whatever graph is already in - the srcWindow. This allows the visualizer to only send diffs when it updates, especially for just edit-point movements - (edit-point is cursor or insertion point..) or changes in sub-tree focus. - 4) Upon receipt of a graph of dispalyObjects, the srcWindow updates its graph then repaints itself. Changes in focus, or - movement of the edit point, etc, show up this way. - 5) GUI gestures are relative to the focused-on-src-phrase (src-phrase is a sub-syntax-tree that forms one phrase or - statement in the language grammar). The gestures are translated from GUI-gestures into editor-commands. - 6) Editor in srcHolder receives the editor-commands from GUI. The commands are relative to current edit-point and - current focused-src-phrase. - 7) The editor modifies the srcTree, including adding new nodes, moving focus, moving edit point, and so on. - 8) Editor tells visualizer the changes it made. It sends a list of nodes that have been modified, including those entering - focus and those leaving focus, and those that gained edit point and those that lost edit point. - 9) Visualizer uses the list of modified nodes to construct a diffGraph to send to the srcWindow.. or else it decides to just - send an entire new baseGraph. - 10) When editPoint changes, the editor sends the visualizer the valid choices selectable in the GUI for modifications to - - - valid is a function of the edit point and the language. - 11) The programmer chooses among the valid options, or types the beginning of the option to have it filled in by the - GUI, or whatever, ending up in - 12 the GUI translating the gesture to an editor command and sending the command to the editor. - Repeat 6-12 - h - Syntax Graph Nodes - How is the syntax graph used? What should the nodes look like? - -- Have to be able to write code (like see to the left, when this was written) that says what node to add for each - - GUI Gestures are allowed relative to the new syntax node.. for example, adding a root of a compound - syntactic entity enables GUI gestures for adding the sub-portions of the compound syntactic entity. Those - GUI gestures only become possible to the person interacting after the root of the compound syntactic entity - has been added. - The Visualizer is responsible for telling the Display what GUI Gestures are allowed relative to each - GraphicalElement. (Maybe should change the name to Visual Element..) - So, on the long drive, seeing a few things: - -- have case with Tensor notation where have the column things.. those are not visual, and they don't have any - semantic meaning, they are purely mechanics of the grammar of the syntax. - -- When do src manipulation, will have custom syntax, and a srcManipulator won't know what to do with this - - - efficiently onto hardware with part structure.. - -- Leaving re-writing till later.. only concentrate for now on something that enforces the grammar, allows - custom grammar for new custom syntax, and is visualizable with custom visualization that turns the custom - syntax into a standard GraphicalElement chain. - -- When add a custom vector graphic, will have boxes denoting inputs placed at particular locations.. want - those locations to be defined as part of defining the custom syntax.. the box locations are known by the - visualizer but not by the Display.. the visualizer creates box GraphicalELements are the appropriate - locations relative to where it places the custom vector graphic, and it sizes all appropriately. Thus, the - visualizer receives code as part of the custom syntax definition that gives the visualizer the info it needs to - place the boxes in the appropriate locations.. and then to put other symbols in those locations once the boxes - get filled in via GUI gestures. - -- The syntax graph nodes are only used for getting the grammar correct while building the graph.. so the - editor receives info in the custom syntax specification that tells it what syntax-graph-element to place at the - insertion point in response to a particular GUI gesture. The editor relies on the Display to have obeyed the - directives given to the Display by the visualizer.. these directives cause the Display to only allow - grammatically correct GUI gestures to be made by the person. - -- The Visualizer receives information as part of the custom syntax spec that it sends along to the Display. This - information is attached to each GraphicalElement and embodies the grammar of the syntax. The information - tells the Display what GUI gestures are allowed in relation to each graphical element the Visualizer sends to - the Display. - - These GUI gestures may be drop-down menu entries, or right-mouse menu entries, or valid keyboard - strokes.. each menu entry is present only when that GUI gesture is allowed. From many GUI gestures, they - are only allowed when a particular node is focused on. So, the mouse-menu and valid keyboard strokes - change as the focused-on GraphicalElement changes. - -- It is expected that many different types of Display will be written.. each will handle focus, and Display- - relative commands like zoom and pan and probably font (but have to wait and see if practical).. and - thinking some kind of intermediate thing specifies the GUI gestures that are valid.. then one Display can - indicate the valid gestures as drop-down while a different one indicates them by icons on a pallette or - something.. - -- It is expected that many different types of Visualizer will be created. It might be best to determine font in the - visualizer rather than in the Display.. Font is important.. different fonts will have different semantic - meaning.. for example, with Tensor notation, which has abstract indexes.. those indexes are characters.. the - characters represent something that has meaning only in that they get matched with other such characters.. - meanwhile something needs to represent free-choice inputs to a syntactic entity.. - - for example, may want to define something that has two free inputs on the left side, and has two holes on - the right side where there are input boxes of a syntactic entity that have not been filled in. Need some way to - indicate which of the left-side inputs should be shuttled over to which of the right-side holes. Can do this - with arrows, but want to be able to do it with variables also.. so, have a special font to use for this purpose.. - thinking an italic font.. so then in the case of Tensor notation, have on the right hand side a Tensor entity - that has 6 index columns, with 4 of them filled in with letters.. well, those letters are literal for the FIRST re- - write that takes place.. the two empty columns require that the left-hand side have a letter that matches to a - same letter on the right-hand side in one of the empty columns. This is why different fonts are needed with - different semantic meaning. - -- Will have multiple Visualizers in each processor that can be visualized. Note that only Holders and Spaces - can be visualized.. processors that are performing number crunching it's not clear.. it is expected that they - get significantly rearranged for the purpose of specialization.. which says one can't see in to them because it - will be a hardware-specific thing that is who knows what.. at the same time, one wishes to debug, so one - wants a verbatim view of processors corresponding to the original source-specified processors, and one - wants a view of datums moving among these processors. - - Thinking perhaps have some kind of debugging option that does a non-optimized specialization that allows - each processor-shape specified in the source code to be see-able in a visualization of a processor created - from that source. And, to be able to tag datums flowing among those processors and get some kind of - visualization of the interleaving of data flows and whatnot, for seeing unexpected need for atomicities and so - forth.. - -- Seeing maybe some kind of unique ID given to each syntactic entity.. there will be many Visualizers for a - given srcHolder, for example.. have to be able to match up something.. what was I thinking about while - driving? - -- This syntax is not interpreted form.. - -- Seeing syntactic sub-entities like the Tensor index columns being used in ways like letting a variable stand - for either a raised or lowered abstract index, which gets picked off from somewhere else and landed in there. - -- One biggie is re-use.. the thing about being able - -- Seeing have a symbol stand for an entire worksheet.. for example, construct this worksheet that has multiple - processors on it, some srcManipulators, and creator spitting out a processor created from the manipulated - source, and so forth.. that whole thing has some input ports and some output ports. A custom symbol is - created, and the inputs on the symbol attached to the inputs on the worksheet, the outputs on the symbol - attached to outputs on the worksheet.. then that symbol can be placed on some other worksheet.. - - Let's see.. can such a symbol be placed directly into EQNLang source? Question here is whether have - - - the into.. now, talking about getting actual, already created and running processors as the into.. the first is a - manipulation of data inside a srcHolder, the second is modifying the namespace of a workSheet and - invoking OS commands to translate, create, and place.. - - So, have one unified language where all that is mix and match, or make a separate architectural language? - - Has implications for the syntax graph, and how re-write happens, and so forth - -- The syntax graph is going to be close to the surface.. it's close to the visual elements, and not yet in the form - that would make sense for executing.. it's a raw form that is expressly for entering correct grammar and - visualizing it.. - - Worry about semantics of the syntax later.. when do, will probably end up modifying the syntax approach - quite a bit, but for now, just concentrate on getting the syntax entered, and entered in a way that have the - flexibility to define matchable and substitutable patterns.. - -- Want the := definitions to have a simple mapping to from-intos.. want to be able to enter from-intos - directly.. worry about making them pretty later.. for now, just make entering from-intos display straight - lines, maybe in a grayed or a light color or something, between the from-location and the into-location. - -- Starting to see this.. have things that specify the node, call it node Foo, that corresponds to a custom- - notation.. have things that specify the grammar for what other nodes can be added in which parts of the Foo - node (children, parent if have special non-symmetric parent reqts).. have things that specify the GUI - gestures to indicate adding a Foo node.. have things that say how to break a Foo node into a - GraphicalElement representation of it. - -- Have a tool that can grab a vector graphic into, then drag boxes to locations around that graphic. If a - compound syntactic entity is what are building in the tool, then define the sub-components and state the - grammar for which sub-components can go where. The sub-components are also built in the same tool. - -- the tool will generate a from pattern, to which one assembles an into pattern and connects parts of the from to - parts of the into. This tool will spit out all the things needed to give to the Visualizer, the Modifier, the - Display, and the re-writer (The Modifier == Editor before) the Modifier gets the piece that constructs an - actual syntax-node(s) in response to a GUI gesture.. so that's where the actual syntax node that goes into the - Model is defined. The Model is passive so it doesn't get anything generated by this tool. The re-writer gets a - separate syntax-tree of the from-into pattern.. - -- Thinking the from-into patterns have to be visible in the srcHolders as well.. not sure what want - visualization to be.. when browsing, will be at some level of the code, and want to see the from-into for a - particular symbol.. - - - - - - - - - - nodeType: childList - semanticProperties: memProcessor - syntacticProperties: name, resolves, compound - resolvesToProperties: TensRep - commandFromGUI: addLocationNode - - type: TensRep - childList: - childList will be filled in over time by further GUI gestures. Each - element of the list will be a Tensor Index Column that resolves - to what a TensRep needs to pull-out values from its multi-set - In semanticProperties, stating that this - name stands for a memory processor, - rather than standing for some other - expression somewhere else - In syntacticProperties, stating that this is a - name (meaning a variable, so see a char - string), that this node resolves to a - syntactic entity that has properties, and - that it is a compound node so the - children are part of the same syntactic - entity - - - entityProperties to match between head - of link and tail of link - Hmmm.. it should be known that a - TensRep is a memory processor by - looking at the definition of TensRep - given elsewhere. - - - - - - - - - - nodeType: twoChild - syntacticProperties: command, resolves, - - (commandName: plus) - commandFromGUI: addCommandNode - - type: plus - resolvesToProperties: copyFromChildren - Modifying what used to be here.. the goal is to state the - syntax-graph node that is to be created upon receiving - each kind of GUI gesture from the Display (SrcWindow). - The SrcWindow's gesture is translated into a modification - command inside the Modifier. - The first command to look at is for the following situation: - the person is on a new, blank, line-position and right- - mouse clicks to add a command node. - Q: make an empty command node first, then fill in the - command? Or know the command already when create - the node? - A: for the moment, know the command when create the - node. However, for now, don't know any of the links. - So, the GUI gesture is only to create an empty command- - node for a particular command. - child1Link - child2Link - Dec 08 Clarifications and Modifications - tokenType - state tokenType allowed inside each box -- - tokenType is more than just visual, a - tokenType exists for each type of thing can - be displayed.. - -- note that there's one tokenType, italic, for a - variable that is an input, and a different - tokenType for a variable that is a - - - variable.. whereas the italic-input-variable - will be replaced (an italic-input-variable - - - -- there is a tokenType for integers, a tokenType - for dimension that can be placed in the - index position of a tensor, a tokenType for - variable, a tokenType for input, a - tokenType can be defined to indicate any - - that tokenType can be used, along with - restrictions on the characters (ie, one can - define a tokenType that can only have the - integers from 1 to 50).. or can define a - tokenType that one must query a processor, - during evaluation of a grammatic sentence, - to find out what the allowed character- - values are (for example, ask the particular - TensRep what is its working dimension, or - attach the dimension as a value to the - tensor-phrase, and make the tokenType - only take values from 1 to that dimension - --> this would be compatible with the way - Gabe wants to use Tensors for his electron- - states thing, where each tensor has a - different dimensionality == number of - allowed states or something like that. - - - The modifier keeps track of the - insertion point - and - uses it to choose where to put the node or value. - nodeType is to indicate what fields will be in this particular version of a - syntax-graph Node.. see discussion of properties.. - syntaxDataType is the type of syntactic-entity.. this is customizable.. this is - used to match to type-of-link-to-is-acceptable.. in some node-types, have - links to other nodes, and a list of acceptable syntaxDataTypes that can be - linked-to - TokenType is what kind of thing can be used to represent the node.. in this - case, either a variable of type TensRep, or an input-box filled by some - expression that resolves to a TensRep - -- note, this is from way back, wasn't thought-out from implications point of - - of view.. so it's a bit inconsistent as far as implementing a type-deduction - system and a consistent grammar.. the properties are fudged together here.. - has to be re-done according to what worked out below. - Want a type that says what shape the syntax-node has - Want properties that describe the resolves-to of nodes that resolve - (in other places, want to know what properties must be possessed by a node - before it can be placed at the end of a particular link) - - verbatim typed in by person using GUI - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - CTOSSpace - - - - - - - - - - - - - - - - - - - - - - - ExternalTunneller - - - - - - - - - - - - - - - - - - - - - - - Name Searcher - - - - - - - - - - - - - - - - - - - - - - dataHolder1 - - - - - - - - - - - - - - - - - - - - - - - dataHolder2 - - - - - - - - - - - - - - - - - - - - - - - dataHolder3 - - - - - - - - - - - - - - - - - - - - - - - CD-ROM - (Appears as an - External processor) - - - - - - - - - - - - - - - - - - - - - - - Authenticator - - - - - - - - - - - - - - - - - - - - - - - Creator - - - - - - - - - - - - - - - - - - - - - - - Importer-Exporter - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Other CTOS Instance - - - - - - - - - - - - - - - - - - - - - - - Web Server - - - - - - - - - - - - - - - - - - - - - - - - - FooBarWorkSpace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //images from Hubble - Format: RGB - - Date created: Jan 23, 2006 - - - - - - - - - - - - - - - - - - - - - - - - MyEqns - - - - - - - - - - - - - - - - - - - - - - - - - - - - - receive processor - - - imageHolder - - GabeImageProcessor - - - - - - - - - - - - - - - - - - - - - - Integrate - fn - result = - result - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - x - - - - - - - - - - fn dx - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Creator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Translator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - receive processor - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //Predicted Images - Format: Foobar - - Date created: Jan 24, 2006 - imageHolder - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Creator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Translator - - - - - - z := 22 - x = foo( x, y ) + z - x - - bar - - x - - y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FooBarProgramSpace - IntegrateManipulatorProgramSpace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ExternalTunneller - - - - - - - - - - - - - - - - - - - IntegrateEqnManipulator - - - - - - - - - - - - - - - diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Ja_14___EQNLang__ideas_on_define__programSpace.pdf Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Ja_14___EQNLang__ideas_on_define__programSpace.pdf has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Ja_14___EQNLang__ideas_on_define__programSpace__OrigCTOSFig.pdf Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/08_Ja_14___EQNLang__ideas_on_define__programSpace__OrigCTOSFig.pdf has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/09_Jn_10___Examples_of_Source_while_editing.odg Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/09_Jn_10___Examples_of_Source_while_editing.odg has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/09_Jn_10___Examples_of_Source_while_editing.pdf Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/09_Jn_10___Examples_of_Source_while_editing.pdf has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/09_My_26___HamiltonianPath_in_EQNLang_crappy_conversion.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/09_My_26___HamiltonianPath_in_EQNLang_crappy_conversion.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,64639 +0,0 @@ - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Slide - Group - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Master slide - - - Group - - Drawing - - - - - - Partial Arguments with “ := ” - - - - - - - Notice that in something of the form: - - - - - - - - Drawing - - - - - - - - - N := M*I + R - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - Q := N - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - b - - - - - - - - Drawing - - - - - - That the LHS of the second definition only takes a single parameter, whereas the RHS takes two. This is a funky case because - - - tensor notation can have a number or a variable name there, and the variable name is not a variable but by being a name it - - - indicates that it should be used to match to other names, and eventually successively substituted with 1 to NumDimensions. - - - Notice that the “b” is not an input-variable, but a “constant” variable - - - Tensor notation needs a way to specify, in a “ := ” definition whether are placing a symbol or a variable that can resolve to a - - - symbol. - - - This is done by having different fonts.. one font says “this is a variable that may resolve to either a symbol or an integer in the - - - range 1:numDim”, and another font that says “I am a symbol used for matching and then substituted with 1:numDim”.. - - - The fonts are defined in the tensor notation definition. - - - Here, using italics to indicate that the name is a variable that is substituted with either a name in the non-italics font or else an - - - integer in the range 1:numDim. - - - The second definition specializes the first definition by filling in one of the two parameters. The “b” is non-italic because it is a - - - symbol rather than a variable. - - - This is a little bit weird because the “ - - - - - - - - a - - - - - - - - ” may resolve to a symbol as well, and - - - - - - - which - - - - - - - symbol it resolves to matters.. - - - For this reason, “:=” definitions may only be used within the same srcHolder they're defined in. - - - For “:=” definitions in a library, the library-def must first be reference-copied into the srcHolder, then it may be used lower and to - - - the right.. - - - Going with MathCAD style worksheets.. “:=” definitions can be used below and to the right of the definition. A srcHolder holds - - - one worksheet. Notice that a worksheet can be iterated by sending out a data-struc that holds the values being used in the - - - worksheet, and having that data-struc looped back to the input of the derived processor made from the worksheet. When - - - the iteration is complete, send the data-struc, or some sub-set of it to a different output port that sends the results on to - - - something else. - - - Do sequences of partial evaluation.. after first, will have something, then can perform another, and so on, until down to only - - - primitives. By using the box notation, no issues with “fresh” variables. Empty boxes left when all down to primitives are - - - inputs to the processor - - - This scheme allows arbitrary expressions on the LHS of the “:=”, as well as the RHS.. this enables partial arguments, where a - - - “function' is called but not all the arguments are given, and it enables using custom notation on LHS, and so on. - - - - - - - - - Drawing - - - - - - Functions as Arguments and repeated - - - LHS matching - - - - - - - A function is the LHS of a “:=” definition, especially if the LHS has variables that substitute into the RHS. So, a “:=” can be - - - defined that takes the LHS of a different “:=”. The action of either the consolidator or the translator (leaning toward an - - - incremental consolidation that will do this, so can type-check at same time, all the way down to primitives, so programmer - - - knows right away if they have passed in a function that doesn't work) -- is to find all LHSes that match, perform the - - - “from” “into”, then look again to see if the result of the “into”s has enabled any more LHS matches, and keep going until - - - no LHS matches found. - - - So what will happen is that the “solid” parts of the LHS are placed in the position of a box. Those LHS solid parts are then placed - - - where the arrows go from the box into the “into” part. After that, those LHS solid parts should have landed in a place in - - - the “into” such that its parameter-positions are filled in. Now, the consolidator or translator will look again at the result of - - - the “into”.. it will see the LHS solid parts with all the parameter positions filled in, will see that as a match, and perform - - - the “from” “Into” for that LHS.. - - - Likewise, the RHS of a “:=” definition can use partial-fill functions that are defined in other places, and have embedded “from” - - - “Into”s and so on.. as long as repeated match followed by “from” “Into” replacements can be done all the way down to - - - primitives, it's fair game. - - - - - - - - Drawing - - - - - - Partial Evaluation Ending in Custom - - - Defined Operations - - - - - - - In order for translation to result in only machine primitives, the partial evaluation that preceeds the translation must reduce everything to - - - language primitives. For this to happen, an operation must either reduce entirely to primitives applied to a set of known data types, or to a - - - set of primitives plus another operation applied to a set of data types. - - - That other operation must follow the same rule, and eventually all chains of operations descending must end in operations that are entirely - - - primitives. - - - This is the pattern fit by an IndexedTensRep that has matching abstractIndexes. It reduces to an ellipsis over the dimension of the indexes - - - PLUS an embedded selection operation inside the ellipsis body. The embedded selection is also custom defined, but its invocation cannot be - - - replaced by primitives because the dimension is not known until run-time. (Hmm, will on further thought, maybe it can be reduced entirely - - - to primitives.. oh well, for purposes of discussion, just pretend that it can't). - - - The trick that makes this acceptable to the translator is to add a traditional procedure call as a primitive. Then, any invocation of an operation - - - that fits the above criteria can be turned into a primitive. - - - - - - This is how it is fine for an IndexedTensRep that has matching abstractIndexes to reduce to a custom-defined selection operation. It is partial - - - evaluated to an ellipsis with primitives plus an invocation of a custom operation in its body. That invocation is then itself turned into a - - - primtive, a procedure call. Therefore the operation is entirely reduced to primtives, it's just that one of those primitives is a call to another - - - custom-defined operation (which itself is reduced to all primitives in the same way). - - - This works because the operations in the call chain are all known before translation. None of them are the result of syntax tree manipulations. - - - Each operation in the chain is either fixed, or it is one case of an IF or a SWITCH. No operations can sneak in whose form is unknown until - - - run-time, all that is unknown is parameter contents and which procedure will be called. - - - - - - - - Drawing - - - - - - Worksheet-defined Variables Used in - - - RHS of := - - - - - - - Seeing, when put variables into RHS that are matched from environment, that there is an indication of the variables that need - - - to already be defined in the worksheet.. - - - Can put names into RHS that are looked up in the environment.. thinking only allow names defined on the same worksheet - - - (inside the same srcHolder).. If want to have them in a library thing, then have to copy the library thing or include it by - - - name onto the worksheet - - - - - - - - Drawing - - - - - - Data Structures are Generated - - - - - - - seeing simply using variables the way want to use them, just assume the data struc has already - - - been defined with the field want it to have. During consolidation, the consolidator generates - - - the data structure such that all uses are covered.. - - - During source editing, have a background process running in the programSpace that does the - - - data-structure generation. It gives visual cues to the programmer.. for example, seeing - - - writes as the things that cause a field to be added to a data structure. Reads, then, are - - - flagged as error until a write shows up somewhere that puts the field being read into the data - - - structure.. - - - Thus, if want a field named “foo”, just say myVar.foo.. and that field will be put into the data - - - structure.. sure there are things have to be careful with related to linked memory processors, - - - but worry about that when doing the details of implementing, and just put restrictions on that - - - that GUI tells programmer about as they try stuff.. - - - Name data-structures at the inputs to a srcHolder bit of code, and when create a new instance.. - - - elsewhere in the code, use type-inference to figure out the data-type.. if can't infer the type, - - - then programmer makes explicit.. but think will be able to infer everywhere inside given just - - - those two places declared. - - - - - - - - Drawing - - - - - - Search Primitive in Language - - - - - - - On the search as primitive.. have to have separate bookeeping data for each parallel thing doing search.. that - - - bookkeeping tracks position in the search tree.. it is the state of a higher-level processor.. seeing it as the bundle that - - - flows through a CT circuit.. have all the stuff need to specify position in a computation in that bundle of state. - - - This means that any marks made on nodes that the algorithm uses to track progress must be placed into the bundle rather - - - than into the node. - - - Seeing either allowing a standard search algorithm to pick the order of node visits any way it wants, or having a library of - - - such algorithms, where each is good for a particular kind of graph, or giving the search algorithm a next-node plug- - - - in. - - - Seeing the next-node plug-in as being a heuristic this uses local information plus its own history -- it is given a set of - - - neighbors and chooses one -- or possibly it is given the current node in the graph and told to pick a new node, - - - however it wants (but it would be responsible for ensuring complete coverage, I think, which would eliminate most - - - of the value of having a primitive).. - - - The primitive will handle making sure that all nodes get traversed. It encodes the underlying backtracking. - - - The primitive also handles the parallelism in the search. It makes the plug-in keep its own history, so it is free to fire off - - - as many search-threads as it likes. In this case, the primitive must encode the underlying back-tracking. That is how - - - it ensures that each search-thread covers a different and distinct sub-set of the search-tree. The back-tracking - - - algorithm simply generates the search-tree by unfolding the graph. Thus, the primitive is free to start each thread on - - - a different fold -- need to show details of backtracking to show precisely how this works. - - - Following this idea, the primitive is given both a data-structure and the chooser-heuristic.. The primitive takes care of - - - backing up when the child list is empty.. the primitive also takes care of tracking which nodes have been tried.. The - - - nodes themselves cannot be modified during a search.. the heuristic is not allowed to modify anything, only read. - - - Once a match is found, the primitive is done, but thinking good idea to keep its place, in case want to modify node then - - - keep looking.. as long as the modification doesn't invalidate the portion of search that has *already* taken place.. in - - - general, this requirement means the modification is not allowed to turn non-matches into matches (but I think it's - - - okay to turn matches into non-matches? Have to look at semantics of graph and of modification and of search results - - - to make sure the modifications don't violate the semantics of what it means to the application for a portion of graph - - - to have already been searched -- ie, a property is a computation result -- the application expects a property to hold - - - on the portion of the graph already searched. Primitive behavior has to be such that once the property holds, it - - - continues to hold -- ie, if getting the correct answer relies on the property holding, then the search path cannot cause - - - the property to stop holding once it has been found to hold, else can get the wrong answer).. - - - - - - - - Drawing - - - - - - Iterations of Equations - - - - - - - So when want to have iterations, like in MathCAD, wanted to iterate the worksheet had the IWin - - - model on it.. put the worksheet in a loop.. have a separate Holder that put all the starting - - - variable values into, send that holder the command to stream its contents out, via GUI or some - - - other processor.. the work sheet that has the equations to be iterated in it has an indication of - - - the system of processors made from the equation-source.. that system is connected to the - - - Holder that generates the starting-values stream. The system receives the stream, the - - - equation-processors do their thing, this creates another stream on the loop-back output, and so - - - on, finishing with a stream sent to the “answer” output. The loop-back output, wraps around - - - and joins with the initial-values path.. Can even single-step this process, see what stuff looks - - - like after each iteration.. - - - - - - - - Drawing - - - - - - Communication Flow caused by Using - - - Custom Notation in an Equation - - - - - - - Write the steps, starting with GUI, going to the editor, back through visualizer, back to GUI.. until a phrase or command-sentence is complete, then - - - show the steps of editor sending sub-tree to generator-manager, which sends it on to a generator-processor, which manipulates the syntax- - - - tree, sends the generated tree to the programSpace, and sends the name back to the originating editor.. the editor replaces the “to be - - - generated” in its sub-tree with the name of the generated code that has now been added to the programSpace. - - - -- draw a picture of the flow, one step in each box - - - - - - - - Drawing - - - - - - Pattern and Property and Search - - - - - - - Seeing a “property” as a name attached to a pattern. If the pattern matches a thing, then the thing “has the property”. - - - The pattern might (probably usually is) in a transform space. The thing is transformed one or several times, then the - - - pattern match performed after the last transform. The transforms will typically throw away information. - - - For example, “has a lot of harmonic content” is a property of a song. Start with a transform that takes the wavelengths - - - of two pitches. A song is composed of time-steps and pitches at each time step for each instrument. Takes two - - - pitches, and transforms to how many wavelengths of each are required for the zero-crossings to coincide again - - - (or come within epsilon). Then another transform that matches these numbers to a “harmonic level”. If the - - - number of cycles of both are large, then the harmonic level is low. If either number is one, then the harmonic- - - - level is max. Next, a transform takes a decaying average of the harmonic level at each time-step. So notes closer - - - in time that have a high harmonic level show up as a higher time-average. Next, a transform takes the average of - - - this over the whole song, and another goes over all the songs it has ever seen and takes the average of these - - - averages. Next, for a given song, a transform takes the difference between the average over that song vs the - - - average of averages over all songs. Then, a number of patterns are attempted to match.. one matches to positive - - - difference. another to a negative difference, another matches to a large magnitude of difference, another to a - - - small magnitude. Finally, the song is given the property “has a lot of harmonic content” if it matched a positive - - - difference with a large magnitude. It is given “has only a little harmonic content” if positive and small, “is very - - - dissonant” if negative and large, and so on. - - - Also seeing “has this property” as an antecedent of a transform.. many transforms can only be applied if their - - - antecedents match to true. So, some transforms will have an antecedent that says “must have FOO property”. - - - also seeing goals. Like in chess program (at least, I imagine chess programs work this way). Have a “current position”, - - - and the way each piece moves is a transform -- or, rather, hmmm.. it's a transform-prototype.. the actual - - - transforms are the moves.. so the prototype is a property. For each piece, all the squares are tested for having all - - - the properties necessary for a legal move (direction of change of squares is a property, have an occupied square - - - along a line is a property, and so on). - - - - - - Seeing that have a ranking of goals -- checkmate is highest rank, capturing a piece is ranked by value of piece, then - - - probably have a bunch of transforms of positions of pieces that end up stating the value of a board position -- - - - want a rank free for the rook, want the bishops close to tie up the knights, and so on.. a human does that, at least - - - I do, and Bill always talks that way about the games when we're done. There are thousands of these sub-goals, - - - and a degree to which each is satisfied -- so, a goal is a pattern.. the more of the pattern that is matched, the - - - more of the goal is satisfied.. the pattern-match comes at the end of a string of transforms, just like the string - - - applied to get from a piece of music to the degree of having the property “has harmony” - - - - - - Seeing that have a weighted-sum transform that is applied -- the goals are weighted (including negative weights for - - - losing pieces).. the degree of match to a goal is multiplied by the weight and all goals are summed, then the - - - highest total is chosen as the action. Humans include their assessment of probability of actions of environment. - - - They construct a tree of possible outcomes of an action, and pattern match to a whole bunch of patterns that have - - - positives and negatives attached (costs or benefits), and match to a whole bunch that modify the environment - - - (ie, “it might be raining”, which modifies the cost-benefit of “play on the beach”) - - - Seeing able to apply transforms in either direction.. if have a trans-to, then one possible action is applying its inverse to - - - get the trans-from, along with knowing that all the antecedent-properties matched (ie, all the antecedents were - - - true). - - - An equation is just a transform that all its antecedents are always true. - - - Having the property “symmetric” (?right name?) means that the transform, take for example, “+”. the result of the - - - transform is the same whether it is “A + B” or “B + A”. So, a bunch of matches have to be done.. can do - - - matches on the syntax tree itself.. that's the way humans work visually.. so, perform the “swap input order” - - - transform (by first matching to the antecedent that “+” must have two inputs, and matching the pattern that - - - identifies the input positions and extracts what's in those positions (here A and B) ). Then applying the - - - transform-under-test (”+”) to both syntax trees (A + B and B + A, which resulted from the antecedent - - - transform). Then matching the results from one transform to the results from the other. -- something like that, - - - made some shortcuts there, but that's the idea - - - A proof is checking antecedents of transforms, then applying the transforms, until all leaf-results match to axioms, or - - - other proven transforms (in a chain that eventually ends with match to axiom-patterns.. axiom patterns have the - - - “true” property, ie, matching an axiom pattern means the thing has the property “true”). - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - type: T, any type that accepts the “add” command - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - type: T - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: lower case name - - - this is box 1 - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: lower case name - - - matches: box 1's contents - - - repeated: zero or more - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: integer - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: integer - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - == - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - The “. . .” command - - - - - - - - - - The ellipsis takes two boxes. The first gives the start and the “stamped out” repeating pattern. - - - The second has the same repeating pattern, but also has a box containing the symbol-data - - - “end”. Any communication between the repetitions is shown between the first box and the - - - second box. - - - The box containing “end” also has a box whose type is boolean. The contents of the boolean - - - box is computed for each repetition of the repeating-pattern. When the boolean box - - - evaluates to true, that is the last repetition put down. Notice, this means at least one - - - repetition will be put down. Alternatively, the second box could contain “repeat when” - - - instead of “end”.. in this case, the repetition will only be put down if the boolean evaluates - - - to true, allowing zero repetitions. The “end” version implies that the lower bound in the - - - summation sign must be less than or equal to the upper bound, and the semantics of the - - - summation is that the upper bound is included. - - - Notice that this style can accommodate arbitrary repeating patterns.. any command, any sort of - - - rule for specializing from repetition to repetition. - - - The index-generation CAN be done by the placer inside the receiving processor.. in this case, - - - the “. . .” is a command to the placer-component of the processor. Then, the indexes are all - - - computed, the bodies are all copied and the substitutions into the bodies are all made before - - - the whole thing gets placed into the working-pattern holder, as one mammoth thing that has - - - all the replicated bodies all in the pattern holder at once.. - - - In another version, the index-generation is not completed.. instead, the boxes for generating the - - - indexes are turned solid.. and the pattern looked up is exactly as shown above, with the - - - dashed lines turned solid.. in this case, “. . .” is a primitive that a primitive-processor - - - understands. That primitive-processor will ship the “repeat” box out, and let the inserted - - - result come back, then the matcher, or the scheduling constraints will cause the next index to - - - be generated, and so forth.. When the end comes back true, the whole thing is replaced by - - - null.. - - - Another version could be that the “. . .” is a command to the src-holding processor, that - - - generates the big, long, sequence and that is what gets fed to the translator.. (but this only - - - works if all the positions are filled in in the source.. if the end-condition for the ellipsis is an - - - input that is unknown at the time of translation, then this version of ellipsis doesn't work.. - - - that input determines how many times the pattern is repeated, so the pattern cannot be - - - generated by the srcHolder at the point that value is unknown. - - - There are likely other versions of ellipsis.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - From - - - - - - - - Drawing - - - - - - Into - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - The “From” and “Into” dashed boxes are src holder - - - commands. They are evaluated by the pattern- - - - definition constructing processor. Their only - - - purpose is to delimit what is the pattern matched-to - - - vs the pattern it is replaced with. - - - - - - - - Drawing - - - - - - Gabe wants to see what he's saying, and the - - - dependencies between the index terms bothers - - - him.. he wants to be able to say “this happens in - - - one atomic action”.. he wants to have a primitive, - - - where he states the relationship between the - - - neighboring - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - Gabe wants different notation - - - that visually indicates that - - - index generation is separate - - - from body evaluations - - - - - - He wants the concept that - - - “oh, yes, the indexes have to - - - be generated.. BUT, once - - - they are, there are no - - - interdependencies among the - - - terms of the series” - - - - - - <What's cool for me is that - - - the elipsis is general FOR - - - loop, and if no arrows go - - - between bodies, then body - - - evaluations are always in - - - parallel> - - - - - - <Explanation that helped - - - was saying that even with the - - - primitive that he wanted, like - - - DOALL loops, the indexes - - - still have to be generated in - - - series, that just isn't shown> - - - - - - <Also helpful is saying that - - - each command is tagged with - - - its properties, such as - - - commutative, associative, - - - distributive, and the translator - - - can look at those and break - - - up according to what - - - properties allow> - - - - - - <He wants to see all the - - - dependencies are in the - - - index, so he doesn't worry - - - about parallelism - - - implications> - - - - - - <Also helped stressing that - - - the word “parallel” is to be - - - stricken from the - - - programmer's head.. only - - - think about “Minimize the - - - dependencies.. nesting of - - - boxes is a dependency, - - - communication of box - - - contents is a dependency> - - - - - - - - Drawing - - - - - - Explain this as a for loop -- - - - the elipsis is general.. any - - - loop behavior can be done - - - with this.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - The blue line - - - connecting the two - - - boxes is a visual - - - indicator that their - - - purpose is a - - - matching operation - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - end - - - - - - - - Drawing - - - - - - start - - - - - - - - Drawing - - - - - - repeat - - - - - - - - Drawing - - - - - - repeat - - - - - - - - Drawing - - - - - - Summation - - - - - - - Summation is defined as a series. Series are translated into Loops. - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - SrcHolder - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - foo - - - - - - - - Drawing - - - - - - - - - M - - - - - - - - Drawing - - - - - - - - - R - - - - - - - - Drawing - - - - - - - - - N := M*I + R - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - out <- - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - less - - - - - - - - Drawing - - - - - - - - - equal - - - - - - - - Drawing - - - - - - - - - greater - - - - - - - - Drawing - - - - - - - - - N <=> 2 - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - 1 - - - - - - - - Drawing - - - - - - - - - 1 - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - out - - - - - - - - - Drawing - - - - - - “ - - - := ” - - - - - - - “ - - - := ” is syntactic sugar (a preprocessor - - - command). What's on the LHS - - - becomes the contents of a “from” box. - - - What's on the RHS becomes the - - - contents of an “Into” box. Further, - - - each italic name on the LHS is - - - matched against each italic name on - - - the RHS. For each match, the names - - - are removed and turned into boxes, - - - then an arrow is placed from the box - - - on the LHS to the box on the RHS. - - - Any arbitrary expression can be on the - - - LHS, and any expr can be on the RHS. - - - - - - when an expr in source matches multiple - - - LHSes, alert the programmer during - - - edit, throw error during consolidation - - - (or something like that) - - - - - - - - Drawing - - - - - - - - - N := M*I + R - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - From - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - Into - - - - - - - - Drawing - - - - - - - - - M*I + R - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - The expr above turns into the - - - custom notation def below: - - - - - - - Notice that there are three kinds of variables that can appear in a ':=' expression. -] One kind indicates that the letter on the left is matched to the same letter on the right to form an arrow in the from-into.-] Second kind indicates that the letter on the left becomes an input box-] Third kind appears on a worksheet or in a spawner and can be on the left side or right. It indicates that the letter is replaced by looking it up in the environment. - - - - - Drawing - - - - - - - - - - - Group - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - From - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - Specification of Define - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - Into - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - From - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - Into - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - The line connecting the - - - two boxes is a visual - - - command to search for - - - all groups of tokens that - - - are of “parameter” - - - tokenType and have the - - - same characters. - - - - - - - - Drawing - - - - - - Pairs found by the blue- - - - line command are - - - connected by arrows - - - - - - - - Drawing - - - - - - Note that search is a primitive here. Can't think of a reasonable way to - - - specify such a search visually without introducing a primitive. There - - - may be something.. - - - At any rate, want to call attention to any place that search comes in to - - - play.. going to be collecting all the places perform search and define - - - a formal syntax for searches.. - - - That's a bit weird verbiage.. Trying to say that search is the key to - - - making a language nice for humans. Take Perl for example.. it has a - - - bunch of built-in ad-hoc searches that it does.. for example, each time - - - something isn't specified it searches for a default to stick in. - - - - - - - - - Drawing - - - - - - To Add on This Page - - - - - - - Ideas for what srcManipulation code will look like - - - - - - - - Drawing - - - - - - Search in source manipulation - - - - - - - Gabe wants to be able to write equations and have them do stuff.. run backwards (ie, match RHS and subst-in LHS) - - - during search of matching patterns, use attached properties during search (IE, state goal of finding sequence of - - - manipulations that ends with eqn has “myProperty” property), be able to state the goals of the search, to - - - automagically perform complex transforms of equations by searching for sequence of patterns can apply.. - - - So.. - - - want a sub-language that is really easy to work with syntax trees.. can spec search.. - - - - - - search for: - - - - - - match to a pattern.. - - - - - - sequence of matches that will get from starting syntax tree to goal syntax tree - - - - - - one or more rule matches that will advance toward a goal -- maybe give back all the choices of found matching - - - sequences.. Gabe was talking about writing down an equation, then wanting system to know that the thing on - - - LHS had certain properties, and things on RHS had other properties, and popping the eqn up as a possibility of - - - something that matched and got closer to goal because replacing one side with other side would change the - - - properties.. - - - Want the search to be aware of properties that are associated with the various sub-trees.. tradeoff between storing all - - - knowable properties with every sub-tree node, vs computing every knowable property on the fly.. - - - - - - - - Drawing - - - - - - The standard syntax tree nodes: - - - - - - - -] leaf - - - -] command - - - -] phrase - - - what else do I need? Where are these going to be used? - - - -] They go to the translator (compiler) - - - -] They are manipulated by primitives for syntax-tree manipulations - - - What kind of syntax tree manipulations do I want to do? - - - -] For generating the Tensor outer product, need to extract info from the input syntax tree, and need to construct an output syntax tree from - - - scratch.. - - - So, want to be able to ask for all nodes with a particular combination of attributes.. for example, “all leaf nodes of TensLowerIndex type” - - - and “the node value of the 3rd child” and “the child with FOO attribute value” - - - That way, don't have to do any tree manipulations, just ask questions - - - To create, want to be able to draw a template and put boxes into it, with arrows pointing to where values should be stuck in.. the values - - - will be pulled from the incoming syntax tree. - - - That way, don't have to do any tree manipulations, just draw the tree I want and indicate where to stick things in. - - - Speaking of which, it might be nice just to draw a template for the incoming tree I expect, and put boxes in the spots I want to extract - - - values from - - - - - - - - Drawing - - - - - - Definition-space Passed Around - - - - - - - Have two cases: in Perl, have global variables, and go to a subroutine where use variables that are defined elsewhere (in other subroutines or in - - - main, or any place).. advantage is don't have to do work of writing down that the variables get sent.. - - - Other case, in Java, everything is Lexically scoped.. a variable is either part of the object in which the function is defined, or it has to be sent as a - - - parameter.. the advantage is that it is easier to keep track of what the contents of that variable mean.. - - - So, how about a hybrid -- have concept of worksheet in MCAD.. any variable defined above and to the left is known at the position one makes a - - - new definition or requests a result be generated.. So the worksheet is a collection of definitions.. In essence, a worksheet is a namespace of - - - defined things.. - - - more precisely, a worksheet is the namespace of a srcHolder processor (or maybe a workSpace processor), and the defines in it are each a collection - - - of memory-processors whose own namespaces connect them up as trees -- the memory-processors are created from the sources that define - - - syntax-tree-nodes. - - - So, what is taking place is that the consolidator, or the translator, whatever does the partial evaluation and resolves syntax-tree-defined-names, is - - - doing a search of each syntax-tree whose root-node is in the namespace of the srcHolder processor. During partial evaluation, each non- - - - primitive name is searched for and substituted. - - - This is communication of variable-assignment syntax-subtrees. - - - So, introduce the concept of definition-spaces.. explicitly draw a definition-space -- equivalent of an MCAD worksheet -- but now, have - - - commands to the partial-evaluator -- these commands allow specifying which definition-space to use when partial-evaluating a given - - - definition.. the commands also allow specifying which definition-space the given definition is put into.. could be multiple.. - - - So now, instead of having only one big definition-space, like in Perl (except when use “my”), or having only tree-spaces like in Java, can now have - - - arbitrary connection between definition-spaces.. have a true graph of definition-spaces and have control over membership rules -- in Java, - - - membership is always “definition-space includes entries in all ancestor definition-spaces in the definition-space tree” with over-riding. - - - But now the idea is to introduce keywords that the partial-evaluator understands that explicitly state the graph of definition-spaces and the inclusion - - - rules on each edge of that graph. (Thinking visually define the graph of definition-spaces -- both within a single worksheet, and among - - - srcHolders in a programSpace).. The keywords allow stating which graph to use to search for names appearing in a given definition, and - - - which definition-space to put that given definition into. Also which graph to use as default to search for names appearing in the definitions - - - in a given definition-space.. - - - So, seeing this as, for example, defining a bunch of widely used definitions (patterns), perhaps like a library, then connecting it into the search path - - - of a bunch of worksheets.. - - - Seeing srcHolder as having built-in commands that the consolidator understands that defines the graph of srcHolders. The graph has directed edges - - - that state the path the consolidator is to follow when searching for the srcHolder where a particular name or command or rule or pattern is - - - defined. - - - Returning back to the example in Perl that sparked these thoughts.. am doing a subroutine but too lazy to pass all the values need, just letting the - - - variables be defined up-above the sub-routine and precede it in run-order.. To be safe and keep myself sane, the equivalent thing I'd do in - - - EQNLang would be to add delimiters of define-spaces.. name the define-space where the names have the definitions I want.. other things - - - may use the same name and indicate the same define-space to resolve that name.. so all expressions that use the same name and indicate the - - - same define-space to resolve that name will see the same definition.. if the definition includes the name of a memory-processor, then all - - - those places where the same name appears and gets looked up in the same define-space will be interacting with the same memory-processor.. - - - if multiple places perform writes, then have to define a directed graph of allowed writer-to-reader communications - - - - - - - - Drawing - - - - - - On Search Primitive - - - - - - - What about using the notion of code structure.. the thing where have a code-pattern in one place, then reference that and override pieces of it - - - in another.. If do that, then the search primitive is just a standard code-pattern that is referenced and override pieces put in.. - - - Going with that idea, the basic pattern is backtracking, with depth-first choice of next node.. then, customize by overriding the choose-next- - - - node portion, and the comparison portion, etc.. - - - The challenge, of course, is that have libraries of highly optimized search code.. want to be able for specializer to recognize when it can use - - - a library, and know how to take the override pieces and generate whatever has to be plugged into the native library code.. - - - Thinking, perhaps, allow grammar on overrides.. could have the srcHolder or something give indication of “standard” points in the original - - - pattern that overrides are hooked in.. then, the libraries are written such that they have a procedure call or something at the equivalent - - - point in the library code. The override-point coincides with the call in the C library code, or MPI library code. - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - Menu-pick-sequence and Comm Var - - - - - - - menu-pick-sequence is when mouse or key-combo initiates right-click menu.. that menu has a number of other menus - - - on it, each is selected by one key that is in the base position of the left hand (can be configured to right-hand - - - base).. - - - for example, “a s d f g”.. one key is pressed, which brings up the next menu in the sequence.. again, the same keys are - - - used to pick another sub-menu, and so on, until the leaf level, where they pick a pattern to insert onto the - - - worksheet. Then, keys are used to navigate to the empty input-boxes and fill them up, or hook them to other - - - things on the worksheet. - - - Programmer has the option of connecting with visible lines, or via using a “communication variable”. A - - - communication variable is the name of a line, the line is simply not drawn. Special kind of assignment means - - - “tail end of arrow” and “head end of arrow”. This implies different semantics than a variable that has state- - - - through-time.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - end - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - repeat - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - 1 - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Op - - - - - - - - Drawing - - - - - - Op - - - - - - - - Drawing - - - - - - Op - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Group - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - To build the pattern for Taylor expansion, turn on “show input boxes”. Then use the GUI to insert a “definition” pattern. This inserts a node of type - - - “definition” into the syntax graph. The Visualizer draws the “:=” for it. - - - The red boxes indicate where “inputs” to a pattern go, which are children of the syntactic-entity (syntactic-pattern) in the syntax graph. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Fill in the rest of the text and input variable names. - - - Use GUI to fill in the “term ==” limit, with “t” - - - Will later add things to RHS that, when this pattern is used, will receive the values placed into the input-variable- - - - name positions. - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Here, a pattern has been added that applies a function to an input-value. This caused an extra level of - - - boxes to pop up, and parentheses to appear. The parentheses are part of the pattern that was just - - - inserted - - - The level of pattern that a particular input-box belongs to is indicated by the physical size of the box, - - - and the embedding.. that is why the LHS box got bigger when the RHS box did. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the second red box of the “...” pattern, and “+” is inserted via GIU. - - - The “...” pattern was defined to have a special Visualizer plug-in that replicates the red boxes, this is what causes - - - the “+” to appear where the corresponding black boxes used to be. - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The text typing is stopped, and instead the programmer performs a GUI gesture to add another child node, which is - - - an “input variable name” node, to the LHS-node of “:=”. This pops up a red box, into which the variable name - - - will be typed. In the syntax graph, this causes one child node, the “Taylor of” text to end, and a new child - - - node, an “input variable name” node, to be inserted. - - - Notice that the GUI knows the type of syntactic node that the insertion point is in, and only allows inputs valid for - - - that kind of node (hence, cannot type raw text into, say, the box where “+” is right now.. the GUI only allows - - - putting binary operators into that box) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the input-variable-name box, and “F” is typed as the name. In the syntax-graph, - - - the insertion-point was at the input-variable-name node, which has the property that the variable-name value is - - - an integer that looks up the text in the srcHolder's data-base (hash table for now). - - - When the typing is finished, the “F” will be saved in the data base and it's lookup-int placed into the property- - - - value of the property node hung off the “input-variable-name” node - - - - - - - - Drawing - - - - - - Next, insertion point is moved to RHS box, and the “...” pattern is inserted via GUI. - - - - - - Only the first boxes of the “...” are red, the black ones get filled in by the pattern itself, inside the Visualizer - - - The “term” is a variable that comes with the “...” pattern, and indicates the position within the pattern. This - - - variable is available via the GUI to patterns embedded within the “...” pattern. - - - The “term ==” is the end-expression. Any var-name that has an integer value that is calculated during the - - - construction of the terms, or a constant integer, can go into the red box. Notice, the type checking has an - - - extra level of work here.. it has to know that calculation happens after the final pattern has been placed onto - - - a worksheet. It has to figure out the result-type of that post-placement calculation. - - - - - - - - Drawing - - - - - - This is the Visualization when the “show input boxes” is turned off - - - for this definition in the GUI. IE, the Visualizer can draw this - - - pattern either with the input-boxes drawn, as shown below, or - - - without, as shown here. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - The insertion point is moved into the verbatim text box and “Taylor of” is typed in. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the LHS box of the “:=” pattern, and a “verbatim text” node is inserted via GIU. - - - This kind of node has text typed into it during definition of the pattern, and when the final pattern is placed - - - onto a worksheet, the text displays verbatim, for the programmer to see. This text has no function other than - - - being useful to the programmer.. in some sense, it is analogous “keywords” in other languages. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Here's how the Taylor expansion is going to be used in end-code: - - - First, the programmer right-clicks at some point on a worksheet, which pops up the first of a sequence of menus. Each - - - menu entry has one o f the left-hand home-position keys as its short-cut. Choosing a menu entry causes another - - - menu to pop up, also with left-hand home-position keys as its short-cuts. - - - Finally, a menu will be reached that has “Insert Taylor Expansion” as one if its entries. Hit the key for that, and its - - - pattern will appear on the worksheet where the mouse right-click was originally performed. (There will also be - - - cursor-movement keyboard commands, so one never has to touch the mouse if one doesn't want to..) - - - Here is what the inserted Taylor pattern looks like: - - - This worksheet view will be seen when a person is viewing the OS instance. A worksheet is a processor placed into a system of processors, that has "below" it a numberof additional processors that are created and connected by using the worksheet. In effect, a worksheet is a GUI-helper for writing programs. It provides a programmerfriendly visualization of a system of processors, and provides a convenient way to create and connect new processors. Each line seen here is a visualization of a processorcreated by using this worksheet. The first two lines are visualizations of syntax trees held in srcHolders, and the last four (five) visualize processors plus their outputs. - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Once all the red input boxes have been filled in with valid entries, the black box will turn into the result of the - - - expansion. The result will be source on the worksheet, just like any other source on it. This source can be - - - attached to data-channels the same way other source is, which causes a live processor to be made from it. This - - - processor will compute on data that comes into the input data-channels, and produce results on its output - - - channels. - - - - - - - - Drawing - - - - - - Here's how to define the Taylor expansion. When the definition is done, it will look like this: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The function application has been filled in by using the GUI to choose to insert input-variable-names - - - from the LHS-node of “:=”. When get to implementation, this process for indicating that the - - - thing inside the box on the RHS is indicating a communication from the input-port on the LHS, - - - might change.. might make the Modifier recognize the variable name is the same, or make the - - - srcHolder make name-spaces for each level of embedding of patterns and do a search among - - - those name-spaces to match variable-names typed in to the RHS, or who knows what.. - - - - - - - - Drawing - - - - - - An interesting question here is “going backwards” during re-write.. for most definitions, either the LHS or the RHS can be matched, and the opposite side substituted in, or even missing elements inferred.. - - - for example, in use, get the arrow, with pre-Taylor on left and post-Taylor on right. What if don't fill in some of the spots on the LHS, and cut-and-paste and expression to the RHS that has some of - - - the boxes filled in that are receivers of inputs from the LHS. Then, there is the information available to infer what has to go in the input-boxes on the LHS, and to fill in the rest of the RHS expression.. - - - in fact, want it to propagate backwards.. so, say the “F” in the LHS was not complete, and the expression pasted into the RHS filled in the missing pieces.. the would want the inferred missing parts of - - - the “F” to propagate backwards all the way up through the worksheet, modifying every ancestor by filling in the missing pieces.. or maybe even asserting that the arrow had to be consistent and forcing - - - changes to the “F” that way, to propagate backwards to ancestors on the worksheet.. - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - This “...” has to pile up right-input operators.. including CONNECTING the sub-expression on the right as the input to the operator to its immediate left. Thinking, if do this, going to need a library of “...” - - - operators that do different things.. this “...” is special because it is a srcManipulation operator. This means the “...” has to include behavior about the syntax graph.. it has to hook nodes in the syntax - - - graph together each time it expands.. this one is specifically for replicating an operator.. so there is one kind of “...” for replicating right-input unary operators, one for replicating left-input unary - - - operators.. and a separate one for replicating binary input operators.. the binary input “...” has the behavior that it manipulates the syntactic-graph such that it connects each middle-term to BOTH - - - binary operators that bound it.. hmmm.. should make it a nesting instead? Need to think about consequences.. implications for parallelism and whatnot.. - - - Yes, keep it as truly binary.. the inputs are attached via links.. have a left-input link and a right-input link.. the target of the left-input link of one binary operator is the same as the target of the right-input - - - link of the neighboring binary operator. The semantics of how the result gets computed is up to the re-writer and the Translator.. There is no loss in making it symmetric, but in contrast there is a - - - constraint that must be “undone” if make it a nesting.. leaving it symmetric leaves the choice of order free from a syntax graph point of view.. the order will be decided by properties attached to the - - - binary operator.. these will be order of application properties - - - Also want to revisit visualizing the “...” pattern.. will have to have special code just for it, because the visualized form does not match the syntax-graph form.. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - This is the pattern for the kind of “...” that replicates a right-input operator. This pattern is specific to right-input unary operators being NESTED, so it knows that there is only one input to the right-most - - - operator, and the rest of the replication is the operator applied to the result of previous applications. Thus, the right-most red box is the thing the right-most operator is applied to. - - - Visualization, to be like the equation wrote above, the way want it, will have to, in effect, perform the operation of “...” somehow during visualization.. will have some kind of thing attached to the “...” - - - operator that the Visualizer invokes that generates a syntax-graph that it gives to the Visualizer. That syntax graph is the one Visualized. - - - See complications with embedding, perhaps, but maybe not if keep structure of these VisualizationGenerators clean.. might be able to get generators inside of generators to come out right.. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - Here, the “term” was gotten by using the GUI.. using right-click menus, selected the “internal” variable from one of the other patterns (the top level “…” pattern) and caused it to be inserted in the input- - - - variable-name box of this “…” pattern. The VisualizerGenerator for this “…” will substitute whatever expression ends up in the input-box for “term ==”, which represents the final term. This means that - - - when the GUI selects the internal variable “term” then there has to be some kind of connection by which the VisualizerGenerator can ask for the end-expression of that internal variable.. the variable has - - - to be of a type that the VisualizerGenerator knows it has an end-expression.. so, maybe, make “…” something that the VisualizerGenerator can query? Or, make some kind of hook or something come - - - with the GUI selection.. maybe the GUI inserts something into the syntax-graph.. or maybe “term” has a property attached.. yes, of course.. give it a property that all VisualizerGenerators look for.. - - - something like “has an end-expression” together with property whose value is the hook to get end-expression or ask for that end-expression. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - term-1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - term-1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Wiggling around here, trying to figure out how to do the replicating derivative thing.. This is - - - something like what want to figure out.. Need some kind of “...” that can replicate a right- - - - input operator the number of times indicated by a value that is input to the “...”. - - - - - - - - Drawing - - - - - - The red box on the right is the input to the right-most replicated right-input operator.. : ) - - - Nailed it. This is what wanted.. so, build up the input-expression inside the box. - - - - - - - - Drawing - - - - - - Added the application of the “F” input to the “x0” input into the box - - - - - - - - Drawing - - - - - - Added the multiply of the F-to-x0 result by the contents of the - - - empty red-box - - - - - - - - Drawing - - - - - - Added a “-” operator, and placed it inside an - - - “exponentiate” operator, and used GUI to grab - - - input-variables “x” and “x0” and grab the internal - - - “term” variable from outer-most “...” – by the - - - way, will have another custom Visualizer plug-in - - - for exponentiate - - - - - - - - Drawing - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - The separately built part has been cut and pasted into the full expression. - - - May have some trouble here with visualization.. the “term” in the deriviative “...” expansion has to be substituted with “2” and then executed to generate the single derivative in the second position.. the - - - value “2” has to be gotten from the outer-most “...” pattern.. communication has to happen during the visualization process, where the Visualizer plug-in that is generating the sub-graph for the derivative - - - “...” gets a value for replicating from the outermost “...” pattern, to replace the “term” value that comes from the outer-most “...” pattern. - - - Also, the “term-1” in the exponent has to communicate with the outermost “...” during visualization of the outermost “...”.. so the outermost “...”'s the one controlling the sending of the “term” value to the - - - internal visualizer plug-ins that receive its “term” variable value. - - - Finally, the exponent has to visualize in a special way.. it is a binary operator, but it visualizes in the way exponents do.. also, when the exponent value is “1” during visualization, it doesn't display at all. - - - The last term of the outermost “...” might go ahead and send the “t” in to the expression, in which case the derivative “...” would expand.. but that's a visualizer implementation thing.. or, more precisely, a - - - visualizer plug-in thing.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - z - - - - - - - - + - - - - - - - - Jacobian(z) - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - z - - - - - - - - about - - - - - - - - - - - - - - 1.213 - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - 4 - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - <pattern - - - - - - - - ( - - - - - - - - t - - - - - - - - ) - - - - - - - - > - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) - - - - - - - := - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - z + - - - - - - - - Jacobian - - - - - - - ( - - - - - - - - z - - - - - - - - ) - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - z - - - - - - - - about - - - - - - - - - - - - - - 1.213 - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - 4 - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - <pattern > - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - make H( - - - - - - - - t - - - - - - - - ) into a processor - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - = - - - - - - - 8.915 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - <processor "H( t )"> - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) = {2.14, 3.919, .. 21.78} - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - = - - - - - - - {1,2 .. 20} - - - - - - - - Drawing - - - - - - - - - - - Drawing - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - A - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - =:= - - - - - - - - Drawing - - - - - - In Hamiltonian path, get a graph.. so - - - have graph data structure - - - Have a root of the graph. - - - have neighbor of each node - - - Q: how to define a data structure? What does it look - - - like? - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - GraphNode - - - - - - - - Drawing - - - - - - nodeValue: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - neighbors: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - 1 - - - - - - - - Drawing - - - - - - N - - - - - - - - Drawing - - - - - - int - - - - - - - - Drawing - - - - - - GraphNode - - - - - - - - Drawing - - - - - - GraphNode - - - - - - - - Drawing - - - - - - Notice that defining a data structure is syntactic sugar for - - - defining a processor. Creating an instance of a data - - - structure is the same as creating a processor. One passes - - - the source for the data-structure to the creator. A data - - - structure definition has implied commands, one to access - - - each element. - - - Other thing is that one doesn't have to define the type of - - - the contents of fields.. the type will be inferred by use.. if - - - it can't be inferred, then the programSpace causes an - - - interaction with the Display and the programmer is asked - - - to fill in. - - - - - - - - Drawing - - - - - - g G - - - - - - - - - - - - - - - - : neighbors - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← - - - - - - - - Gin - - - - - - - - , nodesInPath ← [], graphSize ← - - - - - - - - Gin - - - - - - - - .giveSize - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Drawing - - - - - - The “ . . “ represents a set. The numbers up above - - - indicates that it is an ordered set. The “GraphNode” - - - inside means that each element is of type - - - GraphNode. The “ . . “ is a pattern that was inserted - - - via the GUI - - - - - - - - Drawing - - - - - - So, get a graph-node.. want to explore each neighbor. If do recursively, then - - - saying either that are doing creation of a new processor while running, or are re- - - - using the same processor and passing it a new set of name-space tunnels. - - - - - - Either way, what want to do is have some notion of path or some notion of - - - nodes visited.. Thinking represent path as a set of the nodes visited. - - - - - - There are performance issues here.. the less say the more sophisticated the - - - specializer has to be to get good performance.. the more say the more get in the - - - way of specializers for some hardware. So, if use a primitive that works on just - - - a set, saying less than if use a primitive that works on an ordered set, of the - - - nodes of the graph visited so far.. - - - - - - Start with unordered set.. receive a node in.. want to say that if the node in is - - - an element of the previously visited nodes then dead-end.. otherwise, if the size - - - of the set is equal to number of nodes in graph, then found soln and - - - communicate it out. - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - nodesInPath - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - doNothing - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - nodesInPath : size = = graphSize - - - - - - - - Drawing - - - - - - Set is a primitive processor type of EQNLang.. it has a size field that is defined - - - with an invariant, that it always contains the count of the number of elements in - - - the set - - - - - - Having invariants among fields in a processor is a feature of EQNLang. Any - - - processor that has fields can define invariant relationships among those fields. - - - When such an invariant exists, there can be dependent fields that get automatically - - - updated, or there can be co-equal fields. In the case of co-equal fields, read access - - - is turned off when the invariant is not satisfied. - - - - - - Access to fields is a command sent to a processor, so there can be different kinds - - - of access. The visual may look the same, but when access is to a field that is part - - - of a co-equal invariant, then there is automatically the ability for the processor to - - - send back an “invariant not satisfied” value (??) (in most implementations, this - - - will only come back after the requesting processor has been waiting too long, for - - - example to acquire a lock, and has timed out). - - - - - - The requesting processor can define a handler for this, similar to a try-catch - - - block in Java.. or it can let the exception propagate.. seeing an exception system - - - as in Java.. except just attach the handler, don't see it in the main flow of the - - - code. - - - - - - - - Drawing - - - - - - size == N - - - - - - - - Drawing - - - - - - invariant - - - - - - - - Drawing - - - - - - addNeighbor - - - removeNeighbor - - - - - - - - Drawing - - - - - - In fact, a data structure in EQNLang is essentially the - - - same thing as an object in OO languages. - - - The functions that the memory processor can perform are - - - stated inside the data structure, but defined outside on the - - - same worksheet. - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - - output - - - - - - - - ← nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - output - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← g, nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - Notice a few things happening here: a namespace is being explicitly controlled. There is a namespace-entries-creation at the top - - - that that has “G”, “nodesInPath”, and “graphSize” in it. The “G” is set from “Gin”, which is bold and italic indicating that it - - - becomes whatever is placed in the input position (inside parens here). The name in the “Gin” position names a processor in the - - - namespace that the “H” processor instance finds itself in. (IE, this source is used to make a processor, which is placed into a - - - namespace. The source-name put in the “Gin” position is attached to a processor in that same namespace. If code is placed in - - - the input-position then a name is generated for that code, or else a larger processor is made that combines the “input” code with - - - the “H” code stated here. It is up to the Translator to decide which it wants to do. - - - - - - Notice also the use of the switch construct.. the values on the left of the bar are matched against the result of the expression. - - - The box is replaced by whatever code is to the right of the value that matches the expression result. - - - - - - Just an aside, notice that comparison operators are actually pattern detectors.. they can be considered to check whether the - - - input satisfies a property criteria. The “greater than” property, the “same as” property, etc. There is a difference between the - - - property and the operator that examines an input to determine if it has that property. - - - - - - Notice that the recursion states that the same KIND of processor is given a new namespace.. remember, this is source code, so - - - the arrow is part of source and points to source.. different symbols would be used if one wanted to state that a particular - - - instance of a processor spec were to receive the name-space tunnels created. Only memory processors have internal state, so - - - they're the only kind of processor that it matters which instance one uses to perform a calculation.. for all other processors, it - - - only matters which name-space tunnels it is given.. - - - - - - the dot-dash lines indicate creation of name-space tunnels that are passed to the instance of the processor created from the - - - pointed-to spec. In the case above, a tunnel is made for “G”, “nodesInPath”, and “graphSize”. Whatever source the “H” - - - appears in determines the processor that gets assigned to “G”. The “Gin” is a source-level name, not a processor level name. It - - - indicates lookup in the srcHolders. The “Gin” in the code here has two meanings: anything that appears in that position is - - - inserted into the other side (of the =:=) when re-write is done.. and the other meaning is “Gin is assigned to some expression in - - - the source name-space, by virtue of pattern-matching to the position Gin appears in the definition-source and whatever is in that - - - position in the use-source”.. so the “G ← Gin” means “when a processor is made from a use-of-H-source, make G lookup the - - - same processor as (whatever Gin got assigned to in the source) looks up, now that a processor has been made from that use-of- - - - H-source” - - - - - - The output thing is a bit weird.. the idea is that if the use-of-H appears in an input position, then that input receives H's - - - output, which is represented by “output”.. alternatively, it isn't done consistently here, but had the notion that there could be - - - some way to specify in the use-of-H a name (variable) in that use's source name-space that got assigned to whatever processor - - - output gets assigned to inside of the H-processor. (which would be the nodesInPath processor that got created up at the top) - - - - - - Up at the top, the “ ← []” causes the creation of a new, empty, “set” mem-processor. This happens each time whatever G - - - ended up being copied from changes its contents. IE, if it gets assinged to a different processor, or if the current processor - - - changes it's data contents. This is the semantics I am choosing for EQNLang.. for now.. seems a bit risky with “notification” - - - issues.. - - - - - - Another syntactic-sugar thing, that might be risky for optimization, is the “graphSize” automatically remains in the name- - - - space when the recursive call is made.. - - - - - - this means that an optimizer is going to have to figure out that it has to copy this value to all instances of the H processor it - - - makes.. and it's going to have to figure out that all it has to do to parallelise this code is run it for a short time, breadth-first, - - - making a copy of each nodesInPath each time the add is done.. then it can distribute those copies to different instances of the H - - - processor. - - - - - - This can be figured out from looking at the name-space tunnel creation inside the dot-dashed boxes, and looking at how those - - - names are used. - - - - - - Also, the “g” on the one arrow is just a comment.. the “ for all __ is an element of” is a single pattern.. it assigns “g” to the - - - processors that are inside the set, then passes the resulting name-space tunnel to - - - - - - - a - - - - - - - processor created from the source pointed to. - - - This means that multiple instances of the spec can be created, and a different assignment given to each. - - - - - - The second use of “element of” is a property-checker.. this is a different thing that is pulled down from the GUI.. it results in - - - “yes, an element of the set matches the input element” or “no” - - - - - - Notice that, when parallelism is done, the nodesInPath will have to be copied.. but because nodesInPath is in a name-space - - - tunnel and not inside the H processor it is safe to copy the nodesInPath once for each copy of the H processor created.. because - - - it is passed in, there is no parallelism hazard with modifiying it inside, as long as it is passed back to the same H-instance that - - - did the modifying.. Hmmm, not sure that's even required.. but if more than one mem-processor that were passed in are - - - modified inside, then either need semantics to say whether they have to be kept correlated, or else have to always keep them - - - correlated.. Ahhh.. because the invocation of the H processor starts with a clean assignment to nodesInPath, know that no - - - other processors anywhere else are modifying the same mem-processor that is retrieved by “nodesInPath”. That's the key.. a - - - single invoking input creates a fresh mem-processor, thus giving processors made from this source complete control of the - - - mem-processor. - - - - - - - - Drawing - - - - - - ( - - - - - - - - Gin - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - nodesInPath.add( g ) - - - - - - - - Drawing - - - - - - - A - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - =:= - - - - - - - - Drawing - - - - - - g G - - - - - - - - - - - - - - - - : neighbors - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← - - - - - - - - Gin - - - - - - - - , nodesInPath ← [], graphSize ← - - - - - - - - Gin - - - - - - - - .giveSize - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - nodesInPath - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - doNothing - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - nodesInPath : size = = graphSize - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - - output - - - - - - - - ← nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - output - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← g, nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - Gin - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - nodesInPath.add( g ) - - - - - - - - Drawing - - - - - - ToDo make a figure, out of the above components, that shows a data-structure visually, and shows a “generic kernel” - - - on that structure.. with an equation attached to one element of the structure, and arrows pointing to neighboring - - - elements.. each arrow points to one of the inputs to the equation. - - - A preTranslateSrcManipulator is defined as a standard thing that runs before the re-writer and before translation to - - - machine form. This generic kernel syntax is an input to a plug-in written for the preTranslateSrcManipulator.. - - - the plug-in translates the syntax into something the re-writer understands.. the re-writer is itself a plug-in to the - - - preTranslateSrcManipulator, but it runs last.. - - - Brings up issues about order of plug-ins running.. but that's actually not an issue.. because there is an ordering defined - - - by the syntax graph.. the outer-most are run first.. then any syntax that was inside (either inside a node, or lower - - - down in the syntax tree) is inspected to see if it needs a srcManipulator run on it. - - - BTW, using the notion of “levels” of syntax graph.. the architecture thing, where have architecture levels, where each - - - node of the architecture syntax graph has inside the node, as the node-value an entire graph, which is a sub-graph - - - of a lower-level syntax-graph.. so, can define srcManipulator plug-ins that use this “sub-graph inside a node” - - - thing.. the src manipulator can be written to take the sub-graph and copy it or modify it and connect it in - - - appropriately to the graph the above-node was inside of. - - - For the transform system, the pre-srcManipulated entities have properties attached, and the post-src-manipulated - - - syntactic elements retain properties that link them together as a single syntactic unit.. so the transform system - - - has this pre-manipulation structure, with its properties, available to it.. - - - This allows easy identification of dependency patterns of a generic kernel operating on a parameterized data-structure. - - - And, it keeps all the code of the kernel together in one piece.. so, a divider of the data should be reasonable to - - - define for such generic kernel syntax.. it has to respect the dependencies, that is existent already, compilers - - - understand dependencies and do code transformations based on them.. such a divider-generator would also have - - - to understand side-effects.. that would be built in to the syntax.. it would have to indicate a state-change order.. - - - which is another dependency, in time.. - - - So, have dependencies in space and dependencies in time.. the iteration space is automatically generated from this.. - - - Last thing need is to include syntax that states allowed communication patterns when memory processors are used for - - - communication (side effect). The allowed communication patterns are specified by showing the same kinds of - - - arrows going from statements that generate the result to the memory processor type that receives, then - - - - - - - linked - - - - - - - - - - arrows going to the places that are - - - - - - - allowed - - - - - - - to receive.. this syntax doesn't state that such communication is - - - required, only that it is allowed.. the actual communication operations that carry out the action are specified - - - elsewhere, and state only the memory processor type, and (probably) a reference to the definition of the allowed - - - patterns. - - - This scheme is equivalent to channels in middle-ware.. each channel comes with rules for readers and writers and - - - broadcast.. but this scheme is more flexible on communication patterns.. it can allow complex rules on the - - - allowed patterns.. - - - Note, multiple kinds of names.. just thinking about this.. have names that are in the srcHolder name spaces, and names - - - that are in the created processor name-spaces.. that's the difference between functional languages and imperative - - - ones.. all names in a functional language are in the srcHolder name-space (except recursive, which are sort of - - - also because they cause creation on the fly of new processors from src, in effect.. come back to this later and - - - look closely at it).. however, the name in the source of a memory processor becomes a name in the name-space - - - of the created processors.. in functional, everything refers to srouce.. it all names a shape of processors to be - - - created.. none of the names in a functional ever exist verbatim in the created processor's name spaces (? really.. - - - look closely).. anyway, they never name a specific instance of a processor.. that's the key difference.. when - - - have the name in the source of a specific instance of a processor, then can hand that name to other processors, - - - creating name-space tunnels.. that's the issue.. that's what allows side-effects, and what eliminates the ability to - - - create different instances in different places.. in function just say the shape of processor, not the specific - - - instance of a created one.. so, can always create multiple ones of the same shape and give different – what do I - - - call these? The “context” the pairing of source-names to data-values.. it's a name-space.. but have to think - - - more about what is happening here.. look at the Hamiltonian picture, the dashed rounded boxes shown as inputs - - - are the things I want a name for.. the boxes are explicit syntax for manipulating name-spaces that are given to - - - processor instances, and added to that instance's own name-space.. it's like a tunnel-creation command.. - - - Ahh.. that's what they are.. a “value” is a processor that has specific data in it.. when we think about a “value” what we - - - picture is a memory processor instance that has a state-pattern inside it that we recognize.. the pattern for count, - - - like the integers, or the pattern for character, or the pattern for other “primitive” data type.. a primitive data type - - - is just a pattern of state that we humans have matching patterns for that we use very very often. We have chosen - - - the count pattern because it is used so very often.. We could choose any pattern as a primitive data type.. Float - - - is a model of the pattern we have in our heads that we have recognized in the world and very probably have as a - - - pattern that our very processing elements use in their own state evolution.. that is, neurons directly use - - - continuous numbers.. intensity in to eyes or ears, and my simulated systems I think about seem to work directly - - - in terms of continuous.. rather than logic thinking which uses sharp-edged patterns and jumps from one to the - - - next when required's match.. the rule-patterns are logic in action.. and all the inferences are them doing search - - - to figure out what has to be in order for necessaries to be satisfied for the known-to-be-there resultant to have - - - shown up on the end.. - - - This stuff above about srcManipulator plug-in for syntax graph had me jazzed about the everything-is-a-processor - - - abstraction.. that abstraction is what makes everything here so easy to do and possible to keep things straight.. - - - the difference between srcHolder operations and operations of processors created from contents of srcHolders.. - - - was thinking this is the breakthrough, the key, that will enable human-like processing behavior.. we have the - - - pattern generation from raw details (k-means), and we have search (branch and bound.. chess).. the missing - - - piece is the rule-patterns, and the construction of the system that has all the parts that people have.. the goal - - - system, the pattern-generation.. the pattern-search.. pre-visualization.. and so forth.. the goal system is, of - - - course, our emotional machinery.. with rule-patterns like this, that can be run backwards, plus search, and the - - - source for the patterns held inside processors that can modify the patterns ACCORDING TO THE PATTERNS.. - - - that's the missing piece that can be filled in now. - - - The last thing that's left is the continuous-system stuff.. the things I do where I imagine a dynamic system running and - - - watch what it does.. that gives me predictions, is how I understand mechanical things.. sort of.. there's - - - fundamental in there.. there's the state-tree thing of identifying patterns that simplify larger ones down to less - - - total state.. (notes from the digital design lab taught at UCSC).. anyway, don't quite have a handle on that type - - - of thinking yet, as far as making something that works that way.. perhaps just fuzifying the rule-patterns will do - - - it.. hmmm.. something to think about.. the neurons make the sharp-edges patterns out of continuousness.. so, - - - yeah, find something that has varying degress of fuzyness.. turn down the fuzy to get the sharp edged.. turn it up - - - to get simulated system? Sort of flows along rather than jumping to one stable side or the other.. the neurons - - - learn the flow.. they receive the flow from observation, and generate a setting that matches it.. then can give - - - new inputs to the flow system and watch it flow, see where it goes..? Something like that maybe.. point is - - - something that has features of fundamental, of strength within competing dependent things all vying to set the - - - continuous-value.. oh yeah, the decision-making mechanism, forgot that one, where do the continuous multiply- - - - accumulates, to figure out benefit vs cost.. weighing desires along different chains of things that produce - - - strengths of input.. and have patterns that modify the strength according to kind of strength from other.. ie, “if - - - she's there, then I'll have a lot of flirt-fun, otherwise the best will be maybe intellectual talking with so and so - - - fun”.. or “vanilla together with chocolate syrup” vs “chocolate together with caramel syrup”.. the chocolate is - - - great by itself, the caramel is too, but together, not as great.. meanwhile vanilla good, choc syrup good, but - - - together, multiply the good.. that kind of direct rule-for-interaction-of-continuous.. where “good” is a - - - continuous thing.. amount the pleasure center is pricked.. and the vanilla good interacts with the choco syrup - - - good according to a particular learned pattern.. gained from experiencing the two together.. can do combos in - - - my mind that haven't done together before.. that's how I can come up with new recipe.. I imagine each in my - - - head, have the interaction rules in my head from experience, and imagine the components together.. that's how I - - - figured the duck recipe sent to Ozana.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Modifier - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GUIGestureConverter - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Display - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Visualizer - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SyntaxGraph - - - - - - - - Drawing - - - - - - SrcHolder - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - Modifies - - - Directly - - - - - - - - Drawing - - - - - - Reads - - - Directly - - - - - - - - Drawing - - - - - - Modifier Command - - - - - - - - Drawing - - - - - - DisplayElement List - - - - - - - - Drawing - - - - - - GUIGesture - - - - - - - - Drawing - - - - - - Processor in Syntax - - - - - - - Four kinds of notation for “Processor” in the synatx: - - - -] Sharp-cornered boxes show spec of processor - - - -] Round-cornered dashed boxes show processor-spawner - - - -] Round-cornered solid boxes show already-created processor - - - -] On worksheet, “create processor” has “=>” with created processor on right - - - - - - - - Drawing - - - - - - Syntax that is Fixed - - - - - - - Some primitive parts of EQNLang have fixed pre-visualized-syntax that cannot - - - be overridden: - - - -] The syntx for the different kinds of processor (but can visualize differently) - - - -] The basic parts of a pattern - - - – - - - ]] Fact of having boxes - - - – - - - ]] Fact of placing something inside a box == communication - - - – - - - ]] Fact of being inside a box == rhs of bottom of semantic rule is inside box - - - – - - - ]] Fact of spawner being inside box == “out” port of spawned goes into box - - - -] The “From” and “Into” plus the arrows has fixed meaning - - - -] - - - - - - - - Drawing - - - - - - Processor Spawner - - - - - - - Rounded and dashed box represents a spawner. The Hamiltonian path program - - - is written as nested spawners. - - - -] A spawner accepts an environment as input - - - -] Each time a new environment arrives, a processor is spawned to consume it - - - -] Spawned processors have one or more output ports - - - – - - - ]] Outputs can be connected by Variable on a worksheet - - - – - - - ]] Single output called “output” is connected by default to containing box - - - – - - - ]] Outputs can be connected by letter-match to output ports on left of “:=” - - - – - - - ]] Outputs can be wired directly to input ports of other patterns - - - -] Spawned processor still has the - - - – - - - ]] Inputs can be connected by letter-match to param on left side of “:=” - - - - - - - - Line 1 shows placing a syntax tree on the worksheet. This syntax tree can be "grabbed" by using the GUI and used in other syntax trees or as inputs toprocessors. This is making a pattern by partially filling in a Taylor expansion.The "z" here was selected in the GUI to name an input box. The syntax treewas constructed to have a single input box, visualized each place it occurs inthe syntax tree as "z", and to have an instance of "Jacobian()" pattern, which takes one input, and an instance of Taylor pattern. The input is given to Jacobian, the result added to itself, then insertedinto the Taylor's first input-box. The input is also inserted into the Taylor'ssecond input box. The constant "1.213" goes into the Taylor's 3rd input, and"4" goes into its fourth. Notice that grammar checking of the Taylor's secondinput "with respect to z" happens when "z" gets filled in. - The second line shows making the pattern (syntax tree) defined onthe first line be the right hand side of a ":=". Here, the syntax treeis rooted with a ":=" node, with <function> as left-hand-side, wherethe function name is "H", verbatim, and it has one input-box, whichis named "t". The RHS has the LHS's input-box go to the input-box ofthe pattern defined in line 1. So, when this is used, for examplewith "H(2)" then the "2" will go to the input box of the pattern fromline 1 -- (and, grammar check will say that 2, an int, is not allowed!) - On line 3, the worksheet gets a worksheet variable "t" defined andgiven the value "8.915".. this, of course, is a different "t" than theone that names the input-box of the function-def on line 2. - On line 4, the "make <input box> into a processor" pattern is placedonto the worksheet. The function defined in line 2 is given the worksheet variable defined in line 3 and the combo is put into the<input box>, resulting in a processor. The resulting processor isvisualized as whatever it appeared as in the <input box> for the restof the worksheet. This processor takes the value of the worksheetvariable "t" as its input. Whenever "t" gets changed, the processorwill produce a new result value from t's new value. - IOn line 5, "t" is assigned values from 1 to 20, by putting a processoron the worksheet, visualized as " = { , , .. }", which producessuccessive assignments to the worksheet var that is named on theLHS of the =. - On line 6, a processor is put on the worksheet that visualizes on itsRHS the outputs produced by the processor named on its LHS. - To the left and anchored on the worksheet just slightly below, a processor is placedon the worksheet that visualizes the same outputs from the same "H(t)" processor,but in graph form - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Worksheet Foo - - Drawing - - - - - - - - - - - - - - - - diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/12_Dc_02___Sample_Prog_to_hand_compile.odg Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/12_Dc_02___Sample_Prog_to_hand_compile.odg has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/12_Dc_02___Set_of_main_constructs.odg Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/12_Dc_02___Set_of_main_constructs.odg has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/12_Dc_02___Set_of_main_constructs.pdf Binary file 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/12_Dc_02___Set_of_main_constructs.pdf has changed diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/Foo.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/Foo.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1062 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - Green = VMS-core - Blue = application - Red = plug-in - - - - - - - Physical-Core Controller(pthread) - - - core_loop - - - - - - slaveVP - - - top_VP_fn - - - - Shared Parallelism-Semantic State - - - - - - - Switch VPs - Switch VPs - - - schedSlot - - schedSlot - slaveVP ptr - - - Repeated for each physical core - 1 - - - - - comm_handler_fn - - - - scheduler_fn - - - - localMasterVP - - - - - master_loop - - - - readyQ - - - - 2 - 3 - 4 - 5 - - 6 - 8 - 9 - 10 - - - Switch VPs - Switch VPs - 7 - 11 - (Animated) - (Blocked) - (Ready) - - New Notes for POP - - - diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/Worksheets_and_defining_Taylor_expansion_process.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/Worksheets_and_defining_Taylor_expansion_process.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,64633 +0,0 @@ - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Slide - Group - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Master slide - - - Group - - Drawing - - - - - - Partial Arguments with “ := ” - - - - - - - Notice that in something of the form: - - - - - - - - Drawing - - - - - - - - - N := M*I + R - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - Q := N - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - b - - - - - - - - Drawing - - - - - - That the LHS of the second definition only takes a single parameter, whereas the RHS takes two. This is a funky case because - - - tensor notation can have a number or a variable name there, and the variable name is not a variable but by being a name it - - - indicates that it should be used to match to other names, and eventually successively substituted with 1 to NumDimensions. - - - Notice that the “b” is not an input-variable, but a “constant” variable - - - Tensor notation needs a way to specify, in a “ := ” definition whether are placing a symbol or a variable that can resolve to a - - - symbol. - - - This is done by having different fonts.. one font says “this is a variable that may resolve to either a symbol or an integer in the - - - range 1:numDim”, and another font that says “I am a symbol used for matching and then substituted with 1:numDim”.. - - - The fonts are defined in the tensor notation definition. - - - Here, using italics to indicate that the name is a variable that is substituted with either a name in the non-italics font or else an - - - integer in the range 1:numDim. - - - The second definition specializes the first definition by filling in one of the two parameters. The “b” is non-italic because it is a - - - symbol rather than a variable. - - - This is a little bit weird because the “ - - - - - - - - a - - - - - - - - ” may resolve to a symbol as well, and - - - - - - - which - - - - - - - symbol it resolves to matters.. - - - For this reason, “:=” definitions may only be used within the same srcHolder they're defined in. - - - For “:=” definitions in a library, the library-def must first be reference-copied into the srcHolder, then it may be used lower and to - - - the right.. - - - Going with MathCAD style worksheets.. “:=” definitions can be used below and to the right of the definition. A srcHolder holds - - - one worksheet. Notice that a worksheet can be iterated by sending out a data-struc that holds the values being used in the - - - worksheet, and having that data-struc looped back to the input of the derived processor made from the worksheet. When - - - the iteration is complete, send the data-struc, or some sub-set of it to a different output port that sends the results on to - - - something else. - - - Do sequences of partial evaluation.. after first, will have something, then can perform another, and so on, until down to only - - - primitives. By using the box notation, no issues with “fresh” variables. Empty boxes left when all down to primitives are - - - inputs to the processor - - - This scheme allows arbitrary expressions on the LHS of the “:=”, as well as the RHS.. this enables partial arguments, where a - - - “function' is called but not all the arguments are given, and it enables using custom notation on LHS, and so on. - - - - - - - - - Drawing - - - - - - Functions as Arguments and repeated - - - LHS matching - - - - - - - A function is the LHS of a “:=” definition, especially if the LHS has variables that substitute into the RHS. So, a “:=” can be - - - defined that takes the LHS of a different “:=”. The action of either the consolidator or the translator (leaning toward an - - - incremental consolidation that will do this, so can type-check at same time, all the way down to primitives, so programmer - - - knows right away if they have passed in a function that doesn't work) -- is to find all LHSes that match, perform the - - - “from” “into”, then look again to see if the result of the “into”s has enabled any more LHS matches, and keep going until - - - no LHS matches found. - - - So what will happen is that the “solid” parts of the LHS are placed in the position of a box. Those LHS solid parts are then placed - - - where the arrows go from the box into the “into” part. After that, those LHS solid parts should have landed in a place in - - - the “into” such that its parameter-positions are filled in. Now, the consolidator or translator will look again at the result of - - - the “into”.. it will see the LHS solid parts with all the parameter positions filled in, will see that as a match, and perform - - - the “from” “Into” for that LHS.. - - - Likewise, the RHS of a “:=” definition can use partial-fill functions that are defined in other places, and have embedded “from” - - - “Into”s and so on.. as long as repeated match followed by “from” “Into” replacements can be done all the way down to - - - primitives, it's fair game. - - - - - - - - Drawing - - - - - - Partial Evaluation Ending in Custom - - - Defined Operations - - - - - - - In order for translation to result in only machine primitives, the partial evaluation that preceeds the translation must reduce everything to - - - language primitives. For this to happen, an operation must either reduce entirely to primitives applied to a set of known data types, or to a - - - set of primitives plus another operation applied to a set of data types. - - - That other operation must follow the same rule, and eventually all chains of operations descending must end in operations that are entirely - - - primitives. - - - This is the pattern fit by an IndexedTensRep that has matching abstractIndexes. It reduces to an ellipsis over the dimension of the indexes - - - PLUS an embedded selection operation inside the ellipsis body. The embedded selection is also custom defined, but its invocation cannot be - - - replaced by primitives because the dimension is not known until run-time. (Hmm, will on further thought, maybe it can be reduced entirely - - - to primitives.. oh well, for purposes of discussion, just pretend that it can't). - - - The trick that makes this acceptable to the translator is to add a traditional procedure call as a primitive. Then, any invocation of an operation - - - that fits the above criteria can be turned into a primitive. - - - - - - This is how it is fine for an IndexedTensRep that has matching abstractIndexes to reduce to a custom-defined selection operation. It is partial - - - evaluated to an ellipsis with primitives plus an invocation of a custom operation in its body. That invocation is then itself turned into a - - - primtive, a procedure call. Therefore the operation is entirely reduced to primtives, it's just that one of those primitives is a call to another - - - custom-defined operation (which itself is reduced to all primitives in the same way). - - - This works because the operations in the call chain are all known before translation. None of them are the result of syntax tree manipulations. - - - Each operation in the chain is either fixed, or it is one case of an IF or a SWITCH. No operations can sneak in whose form is unknown until - - - run-time, all that is unknown is parameter contents and which procedure will be called. - - - - - - - - Drawing - - - - - - Worksheet-defined Variables Used in - - - RHS of := - - - - - - - Seeing, when put variables into RHS that are matched from environment, that there is an indication of the variables that need - - - to already be defined in the worksheet.. - - - Can put names into RHS that are looked up in the environment.. thinking only allow names defined on the same worksheet - - - (inside the same srcHolder).. If want to have them in a library thing, then have to copy the library thing or include it by - - - name onto the worksheet - - - - - - - - Drawing - - - - - - Data Structures are Generated - - - - - - - seeing simply using variables the way want to use them, just assume the data struc has already - - - been defined with the field want it to have. During consolidation, the consolidator generates - - - the data structure such that all uses are covered.. - - - During source editing, have a background process running in the programSpace that does the - - - data-structure generation. It gives visual cues to the programmer.. for example, seeing - - - writes as the things that cause a field to be added to a data structure. Reads, then, are - - - flagged as error until a write shows up somewhere that puts the field being read into the data - - - structure.. - - - Thus, if want a field named “foo”, just say myVar.foo.. and that field will be put into the data - - - structure.. sure there are things have to be careful with related to linked memory processors, - - - but worry about that when doing the details of implementing, and just put restrictions on that - - - that GUI tells programmer about as they try stuff.. - - - Name data-structures at the inputs to a srcHolder bit of code, and when create a new instance.. - - - elsewhere in the code, use type-inference to figure out the data-type.. if can't infer the type, - - - then programmer makes explicit.. but think will be able to infer everywhere inside given just - - - those two places declared. - - - - - - - - Drawing - - - - - - Search Primitive in Language - - - - - - - On the search as primitive.. have to have separate bookeeping data for each parallel thing doing search.. that - - - bookkeeping tracks position in the search tree.. it is the state of a higher-level processor.. seeing it as the bundle that - - - flows through a CT circuit.. have all the stuff need to specify position in a computation in that bundle of state. - - - This means that any marks made on nodes that the algorithm uses to track progress must be placed into the bundle rather - - - than into the node. - - - Seeing either allowing a standard search algorithm to pick the order of node visits any way it wants, or having a library of - - - such algorithms, where each is good for a particular kind of graph, or giving the search algorithm a next-node plug- - - - in. - - - Seeing the next-node plug-in as being a heuristic this uses local information plus its own history -- it is given a set of - - - neighbors and chooses one -- or possibly it is given the current node in the graph and told to pick a new node, - - - however it wants (but it would be responsible for ensuring complete coverage, I think, which would eliminate most - - - of the value of having a primitive).. - - - The primitive will handle making sure that all nodes get traversed. It encodes the underlying backtracking. - - - The primitive also handles the parallelism in the search. It makes the plug-in keep its own history, so it is free to fire off - - - as many search-threads as it likes. In this case, the primitive must encode the underlying back-tracking. That is how - - - it ensures that each search-thread covers a different and distinct sub-set of the search-tree. The back-tracking - - - algorithm simply generates the search-tree by unfolding the graph. Thus, the primitive is free to start each thread on - - - a different fold -- need to show details of backtracking to show precisely how this works. - - - Following this idea, the primitive is given both a data-structure and the chooser-heuristic.. The primitive takes care of - - - backing up when the child list is empty.. the primitive also takes care of tracking which nodes have been tried.. The - - - nodes themselves cannot be modified during a search.. the heuristic is not allowed to modify anything, only read. - - - Once a match is found, the primitive is done, but thinking good idea to keep its place, in case want to modify node then - - - keep looking.. as long as the modification doesn't invalidate the portion of search that has *already* taken place.. in - - - general, this requirement means the modification is not allowed to turn non-matches into matches (but I think it's - - - okay to turn matches into non-matches? Have to look at semantics of graph and of modification and of search results - - - to make sure the modifications don't violate the semantics of what it means to the application for a portion of graph - - - to have already been searched -- ie, a property is a computation result -- the application expects a property to hold - - - on the portion of the graph already searched. Primitive behavior has to be such that once the property holds, it - - - continues to hold -- ie, if getting the correct answer relies on the property holding, then the search path cannot cause - - - the property to stop holding once it has been found to hold, else can get the wrong answer).. - - - - - - - - Drawing - - - - - - Iterations of Equations - - - - - - - So when want to have iterations, like in MathCAD, wanted to iterate the worksheet had the IWin - - - model on it.. put the worksheet in a loop.. have a separate Holder that put all the starting - - - variable values into, send that holder the command to stream its contents out, via GUI or some - - - other processor.. the work sheet that has the equations to be iterated in it has an indication of - - - the system of processors made from the equation-source.. that system is connected to the - - - Holder that generates the starting-values stream. The system receives the stream, the - - - equation-processors do their thing, this creates another stream on the loop-back output, and so - - - on, finishing with a stream sent to the “answer” output. The loop-back output, wraps around - - - and joins with the initial-values path.. Can even single-step this process, see what stuff looks - - - like after each iteration.. - - - - - - - - Drawing - - - - - - Communication Flow caused by Using - - - Custom Notation in an Equation - - - - - - - Write the steps, starting with GUI, going to the editor, back through visualizer, back to GUI.. until a phrase or command-sentence is complete, then - - - show the steps of editor sending sub-tree to generator-manager, which sends it on to a generator-processor, which manipulates the syntax- - - - tree, sends the generated tree to the programSpace, and sends the name back to the originating editor.. the editor replaces the “to be - - - generated” in its sub-tree with the name of the generated code that has now been added to the programSpace. - - - -- draw a picture of the flow, one step in each box - - - - - - - - Drawing - - - - - - Pattern and Property and Search - - - - - - - Seeing a “property” as a name attached to a pattern. If the pattern matches a thing, then the thing “has the property”. - - - The pattern might (probably usually is) in a transform space. The thing is transformed one or several times, then the - - - pattern match performed after the last transform. The transforms will typically throw away information. - - - For example, “has a lot of harmonic content” is a property of a song. Start with a transform that takes the wavelengths - - - of two pitches. A song is composed of time-steps and pitches at each time step for each instrument. Takes two - - - pitches, and transforms to how many wavelengths of each are required for the zero-crossings to coincide again - - - (or come within epsilon). Then another transform that matches these numbers to a “harmonic level”. If the - - - number of cycles of both are large, then the harmonic level is low. If either number is one, then the harmonic- - - - level is max. Next, a transform takes a decaying average of the harmonic level at each time-step. So notes closer - - - in time that have a high harmonic level show up as a higher time-average. Next, a transform takes the average of - - - this over the whole song, and another goes over all the songs it has ever seen and takes the average of these - - - averages. Next, for a given song, a transform takes the difference between the average over that song vs the - - - average of averages over all songs. Then, a number of patterns are attempted to match.. one matches to positive - - - difference. another to a negative difference, another matches to a large magnitude of difference, another to a - - - small magnitude. Finally, the song is given the property “has a lot of harmonic content” if it matched a positive - - - difference with a large magnitude. It is given “has only a little harmonic content” if positive and small, “is very - - - dissonant” if negative and large, and so on. - - - Also seeing “has this property” as an antecedent of a transform.. many transforms can only be applied if their - - - antecedents match to true. So, some transforms will have an antecedent that says “must have FOO property”. - - - also seeing goals. Like in chess program (at least, I imagine chess programs work this way). Have a “current position”, - - - and the way each piece moves is a transform -- or, rather, hmmm.. it's a transform-prototype.. the actual - - - transforms are the moves.. so the prototype is a property. For each piece, all the squares are tested for having all - - - the properties necessary for a legal move (direction of change of squares is a property, have an occupied square - - - along a line is a property, and so on). - - - - - - Seeing that have a ranking of goals -- checkmate is highest rank, capturing a piece is ranked by value of piece, then - - - probably have a bunch of transforms of positions of pieces that end up stating the value of a board position -- - - - want a rank free for the rook, want the bishops close to tie up the knights, and so on.. a human does that, at least - - - I do, and Bill always talks that way about the games when we're done. There are thousands of these sub-goals, - - - and a degree to which each is satisfied -- so, a goal is a pattern.. the more of the pattern that is matched, the - - - more of the goal is satisfied.. the pattern-match comes at the end of a string of transforms, just like the string - - - applied to get from a piece of music to the degree of having the property “has harmony” - - - - - - Seeing that have a weighted-sum transform that is applied -- the goals are weighted (including negative weights for - - - losing pieces).. the degree of match to a goal is multiplied by the weight and all goals are summed, then the - - - highest total is chosen as the action. Humans include their assessment of probability of actions of environment. - - - They construct a tree of possible outcomes of an action, and pattern match to a whole bunch of patterns that have - - - positives and negatives attached (costs or benefits), and match to a whole bunch that modify the environment - - - (ie, “it might be raining”, which modifies the cost-benefit of “play on the beach”) - - - Seeing able to apply transforms in either direction.. if have a trans-to, then one possible action is applying its inverse to - - - get the trans-from, along with knowing that all the antecedent-properties matched (ie, all the antecedents were - - - true). - - - An equation is just a transform that all its antecedents are always true. - - - Having the property “symmetric” (?right name?) means that the transform, take for example, “+”. the result of the - - - transform is the same whether it is “A + B” or “B + A”. So, a bunch of matches have to be done.. can do - - - matches on the syntax tree itself.. that's the way humans work visually.. so, perform the “swap input order” - - - transform (by first matching to the antecedent that “+” must have two inputs, and matching the pattern that - - - identifies the input positions and extracts what's in those positions (here A and B) ). Then applying the - - - transform-under-test (”+”) to both syntax trees (A + B and B + A, which resulted from the antecedent - - - transform). Then matching the results from one transform to the results from the other. -- something like that, - - - made some shortcuts there, but that's the idea - - - A proof is checking antecedents of transforms, then applying the transforms, until all leaf-results match to axioms, or - - - other proven transforms (in a chain that eventually ends with match to axiom-patterns.. axiom patterns have the - - - “true” property, ie, matching an axiom pattern means the thing has the property “true”). - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - type: T, any type that accepts the “add” command - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - type: T - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: lower case name - - - this is box 1 - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: lower case name - - - matches: box 1's contents - - - repeated: zero or more - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: integer - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - font: integer - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - == - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - The “. . .” command - - - - - - - - - - The ellipsis takes two boxes. The first gives the start and the “stamped out” repeating pattern. - - - The second has the same repeating pattern, but also has a box containing the symbol-data - - - “end”. Any communication between the repetitions is shown between the first box and the - - - second box. - - - The box containing “end” also has a box whose type is boolean. The contents of the boolean - - - box is computed for each repetition of the repeating-pattern. When the boolean box - - - evaluates to true, that is the last repetition put down. Notice, this means at least one - - - repetition will be put down. Alternatively, the second box could contain “repeat when” - - - instead of “end”.. in this case, the repetition will only be put down if the boolean evaluates - - - to true, allowing zero repetitions. The “end” version implies that the lower bound in the - - - summation sign must be less than or equal to the upper bound, and the semantics of the - - - summation is that the upper bound is included. - - - Notice that this style can accommodate arbitrary repeating patterns.. any command, any sort of - - - rule for specializing from repetition to repetition. - - - The index-generation CAN be done by the placer inside the receiving processor.. in this case, - - - the “. . .” is a command to the placer-component of the processor. Then, the indexes are all - - - computed, the bodies are all copied and the substitutions into the bodies are all made before - - - the whole thing gets placed into the working-pattern holder, as one mammoth thing that has - - - all the replicated bodies all in the pattern holder at once.. - - - In another version, the index-generation is not completed.. instead, the boxes for generating the - - - indexes are turned solid.. and the pattern looked up is exactly as shown above, with the - - - dashed lines turned solid.. in this case, “. . .” is a primitive that a primitive-processor - - - understands. That primitive-processor will ship the “repeat” box out, and let the inserted - - - result come back, then the matcher, or the scheduling constraints will cause the next index to - - - be generated, and so forth.. When the end comes back true, the whole thing is replaced by - - - null.. - - - Another version could be that the “. . .” is a command to the src-holding processor, that - - - generates the big, long, sequence and that is what gets fed to the translator.. (but this only - - - works if all the positions are filled in in the source.. if the end-condition for the ellipsis is an - - - input that is unknown at the time of translation, then this version of ellipsis doesn't work.. - - - that input determines how many times the pattern is repeated, so the pattern cannot be - - - generated by the srcHolder at the point that value is unknown. - - - There are likely other versions of ellipsis.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - From - - - - - - - - Drawing - - - - - - Into - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - The “From” and “Into” dashed boxes are src holder - - - commands. They are evaluated by the pattern- - - - definition constructing processor. Their only - - - purpose is to delimit what is the pattern matched-to - - - vs the pattern it is replaced with. - - - - - - - - Drawing - - - - - - Gabe wants to see what he's saying, and the - - - dependencies between the index terms bothers - - - him.. he wants to be able to say “this happens in - - - one atomic action”.. he wants to have a primitive, - - - where he states the relationship between the - - - neighboring - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - Gabe wants different notation - - - that visually indicates that - - - index generation is separate - - - from body evaluations - - - - - - He wants the concept that - - - “oh, yes, the indexes have to - - - be generated.. BUT, once - - - they are, there are no - - - interdependencies among the - - - terms of the series” - - - - - - <What's cool for me is that - - - the elipsis is general FOR - - - loop, and if no arrows go - - - between bodies, then body - - - evaluations are always in - - - parallel> - - - - - - <Explanation that helped - - - was saying that even with the - - - primitive that he wanted, like - - - DOALL loops, the indexes - - - still have to be generated in - - - series, that just isn't shown> - - - - - - <Also helpful is saying that - - - each command is tagged with - - - its properties, such as - - - commutative, associative, - - - distributive, and the translator - - - can look at those and break - - - up according to what - - - properties allow> - - - - - - <He wants to see all the - - - dependencies are in the - - - index, so he doesn't worry - - - about parallelism - - - implications> - - - - - - <Also helped stressing that - - - the word “parallel” is to be - - - stricken from the - - - programmer's head.. only - - - think about “Minimize the - - - dependencies.. nesting of - - - boxes is a dependency, - - - communication of box - - - contents is a dependency> - - - - - - - - Drawing - - - - - - Explain this as a for loop -- - - - the elipsis is general.. any - - - loop behavior can be done - - - with this.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - The blue line - - - connecting the two - - - boxes is a visual - - - indicator that their - - - purpose is a - - - matching operation - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - end - - - - - - - - Drawing - - - - - - start - - - - - - - - Drawing - - - - - - repeat - - - - - - - - Drawing - - - - - - repeat - - - - - - - - Drawing - - - - - - Summation - - - - - - - Summation is defined as a series. Series are translated into Loops. - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - SrcHolder - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - foo - - - - - - - - Drawing - - - - - - - - - M - - - - - - - - Drawing - - - - - - - - - R - - - - - - - - Drawing - - - - - - - - - N := M*I + R - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - out <- - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - less - - - - - - - - Drawing - - - - - - - - - equal - - - - - - - - Drawing - - - - - - - - - greater - - - - - - - - Drawing - - - - - - - - - N <=> 2 - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - a - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - 1 - - - - - - - - Drawing - - - - - - - - - 1 - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - out - - - - - - - - - Drawing - - - - - - “ - - - := ” - - - - - - - “ - - - := ” is syntactic sugar (a preprocessor - - - command). What's on the LHS - - - becomes the contents of a “from” box. - - - What's on the RHS becomes the - - - contents of an “Into” box. Further, - - - each italic name on the LHS is - - - matched against each italic name on - - - the RHS. For each match, the names - - - are removed and turned into boxes, - - - then an arrow is placed from the box - - - on the LHS to the box on the RHS. - - - Any arbitrary expression can be on the - - - LHS, and any expr can be on the RHS. - - - - - - when an expr in source matches multiple - - - LHSes, alert the programmer during - - - edit, throw error during consolidation - - - (or something like that) - - - - - - - - Drawing - - - - - - - - - N := M*I + R - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - b - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - a - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - From - - - - - - - - Drawing - - - - - - - - - N - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - Into - - - - - - - - Drawing - - - - - - - - - M*I + R - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - The expr above turns into the - - - custom notation def below: - - - - - - - Notice that there are three kinds of variables that can appear in a ':=' expression. -] One kind indicates that the letter on the left is matched to the same letter on the right to form an arrow in the from-into.-] Second kind indicates that the letter on the left becomes an input box-] Third kind appears on a worksheet or in a spawner and can be on the left side or right. It indicates that the letter is replaced by looking it up in the environment. - - - - - Drawing - - - - - - - - - - - Group - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - From - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - Specification of Define - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - Into - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - From - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - Into - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - The line connecting the - - - two boxes is a visual - - - command to search for - - - all groups of tokens that - - - are of “parameter” - - - tokenType and have the - - - same characters. - - - - - - - - Drawing - - - - - - Pairs found by the blue- - - - line command are - - - connected by arrows - - - - - - - - Drawing - - - - - - Note that search is a primitive here. Can't think of a reasonable way to - - - specify such a search visually without introducing a primitive. There - - - may be something.. - - - At any rate, want to call attention to any place that search comes in to - - - play.. going to be collecting all the places perform search and define - - - a formal syntax for searches.. - - - That's a bit weird verbiage.. Trying to say that search is the key to - - - making a language nice for humans. Take Perl for example.. it has a - - - bunch of built-in ad-hoc searches that it does.. for example, each time - - - something isn't specified it searches for a default to stick in. - - - - - - - - - Drawing - - - - - - To Add on This Page - - - - - - - Ideas for what srcManipulation code will look like - - - - - - - - Drawing - - - - - - Search in source manipulation - - - - - - - Gabe wants to be able to write equations and have them do stuff.. run backwards (ie, match RHS and subst-in LHS) - - - during search of matching patterns, use attached properties during search (IE, state goal of finding sequence of - - - manipulations that ends with eqn has “myProperty” property), be able to state the goals of the search, to - - - automagically perform complex transforms of equations by searching for sequence of patterns can apply.. - - - So.. - - - want a sub-language that is really easy to work with syntax trees.. can spec search.. - - - - - - search for: - - - - - - match to a pattern.. - - - - - - sequence of matches that will get from starting syntax tree to goal syntax tree - - - - - - one or more rule matches that will advance toward a goal -- maybe give back all the choices of found matching - - - sequences.. Gabe was talking about writing down an equation, then wanting system to know that the thing on - - - LHS had certain properties, and things on RHS had other properties, and popping the eqn up as a possibility of - - - something that matched and got closer to goal because replacing one side with other side would change the - - - properties.. - - - Want the search to be aware of properties that are associated with the various sub-trees.. tradeoff between storing all - - - knowable properties with every sub-tree node, vs computing every knowable property on the fly.. - - - - - - - - Drawing - - - - - - The standard syntax tree nodes: - - - - - - - -] leaf - - - -] command - - - -] phrase - - - what else do I need? Where are these going to be used? - - - -] They go to the translator (compiler) - - - -] They are manipulated by primitives for syntax-tree manipulations - - - What kind of syntax tree manipulations do I want to do? - - - -] For generating the Tensor outer product, need to extract info from the input syntax tree, and need to construct an output syntax tree from - - - scratch.. - - - So, want to be able to ask for all nodes with a particular combination of attributes.. for example, “all leaf nodes of TensLowerIndex type” - - - and “the node value of the 3rd child” and “the child with FOO attribute value” - - - That way, don't have to do any tree manipulations, just ask questions - - - To create, want to be able to draw a template and put boxes into it, with arrows pointing to where values should be stuck in.. the values - - - will be pulled from the incoming syntax tree. - - - That way, don't have to do any tree manipulations, just draw the tree I want and indicate where to stick things in. - - - Speaking of which, it might be nice just to draw a template for the incoming tree I expect, and put boxes in the spots I want to extract - - - values from - - - - - - - - Drawing - - - - - - Definition-space Passed Around - - - - - - - Have two cases: in Perl, have global variables, and go to a subroutine where use variables that are defined elsewhere (in other subroutines or in - - - main, or any place).. advantage is don't have to do work of writing down that the variables get sent.. - - - Other case, in Java, everything is Lexically scoped.. a variable is either part of the object in which the function is defined, or it has to be sent as a - - - parameter.. the advantage is that it is easier to keep track of what the contents of that variable mean.. - - - So, how about a hybrid -- have concept of worksheet in MCAD.. any variable defined above and to the left is known at the position one makes a - - - new definition or requests a result be generated.. So the worksheet is a collection of definitions.. In essence, a worksheet is a namespace of - - - defined things.. - - - more precisely, a worksheet is the namespace of a srcHolder processor (or maybe a workSpace processor), and the defines in it are each a collection - - - of memory-processors whose own namespaces connect them up as trees -- the memory-processors are created from the sources that define - - - syntax-tree-nodes. - - - So, what is taking place is that the consolidator, or the translator, whatever does the partial evaluation and resolves syntax-tree-defined-names, is - - - doing a search of each syntax-tree whose root-node is in the namespace of the srcHolder processor. During partial evaluation, each non- - - - primitive name is searched for and substituted. - - - This is communication of variable-assignment syntax-subtrees. - - - So, introduce the concept of definition-spaces.. explicitly draw a definition-space -- equivalent of an MCAD worksheet -- but now, have - - - commands to the partial-evaluator -- these commands allow specifying which definition-space to use when partial-evaluating a given - - - definition.. the commands also allow specifying which definition-space the given definition is put into.. could be multiple.. - - - So now, instead of having only one big definition-space, like in Perl (except when use “my”), or having only tree-spaces like in Java, can now have - - - arbitrary connection between definition-spaces.. have a true graph of definition-spaces and have control over membership rules -- in Java, - - - membership is always “definition-space includes entries in all ancestor definition-spaces in the definition-space tree” with over-riding. - - - But now the idea is to introduce keywords that the partial-evaluator understands that explicitly state the graph of definition-spaces and the inclusion - - - rules on each edge of that graph. (Thinking visually define the graph of definition-spaces -- both within a single worksheet, and among - - - srcHolders in a programSpace).. The keywords allow stating which graph to use to search for names appearing in a given definition, and - - - which definition-space to put that given definition into. Also which graph to use as default to search for names appearing in the definitions - - - in a given definition-space.. - - - So, seeing this as, for example, defining a bunch of widely used definitions (patterns), perhaps like a library, then connecting it into the search path - - - of a bunch of worksheets.. - - - Seeing srcHolder as having built-in commands that the consolidator understands that defines the graph of srcHolders. The graph has directed edges - - - that state the path the consolidator is to follow when searching for the srcHolder where a particular name or command or rule or pattern is - - - defined. - - - Returning back to the example in Perl that sparked these thoughts.. am doing a subroutine but too lazy to pass all the values need, just letting the - - - variables be defined up-above the sub-routine and precede it in run-order.. To be safe and keep myself sane, the equivalent thing I'd do in - - - EQNLang would be to add delimiters of define-spaces.. name the define-space where the names have the definitions I want.. other things - - - may use the same name and indicate the same define-space to resolve that name.. so all expressions that use the same name and indicate the - - - same define-space to resolve that name will see the same definition.. if the definition includes the name of a memory-processor, then all - - - those places where the same name appears and gets looked up in the same define-space will be interacting with the same memory-processor.. - - - if multiple places perform writes, then have to define a directed graph of allowed writer-to-reader communications - - - - - - - - Drawing - - - - - - On Search Primitive - - - - - - - What about using the notion of code structure.. the thing where have a code-pattern in one place, then reference that and override pieces of it - - - in another.. If do that, then the search primitive is just a standard code-pattern that is referenced and override pieces put in.. - - - Going with that idea, the basic pattern is backtracking, with depth-first choice of next node.. then, customize by overriding the choose-next- - - - node portion, and the comparison portion, etc.. - - - The challenge, of course, is that have libraries of highly optimized search code.. want to be able for specializer to recognize when it can use - - - a library, and know how to take the override pieces and generate whatever has to be plugged into the native library code.. - - - Thinking, perhaps, allow grammar on overrides.. could have the srcHolder or something give indication of “standard” points in the original - - - pattern that overrides are hooked in.. then, the libraries are written such that they have a procedure call or something at the equivalent - - - point in the library code. The override-point coincides with the call in the C library code, or MPI library code. - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - Menu-pick-sequence and Comm Var - - - - - - - menu-pick-sequence is when mouse or key-combo initiates right-click menu.. that menu has a number of other menus - - - on it, each is selected by one key that is in the base position of the left hand (can be configured to right-hand - - - base).. - - - for example, “a s d f g”.. one key is pressed, which brings up the next menu in the sequence.. again, the same keys are - - - used to pick another sub-menu, and so on, until the leaf level, where they pick a pattern to insert onto the - - - worksheet. Then, keys are used to navigate to the empty input-boxes and fill them up, or hook them to other - - - things on the worksheet. - - - Programmer has the option of connecting with visible lines, or via using a “communication variable”. A - - - communication variable is the name of a line, the line is simply not drawn. Special kind of assignment means - - - “tail end of arrow” and “head end of arrow”. This implies different semantics than a variable that has state- - - - through-time.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - end - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - + 1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - repeat - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - 1 - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Op - - - - - - - - Drawing - - - - - - Op - - - - - - - - Drawing - - - - - - Op - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Group - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - To build the pattern for Taylor expansion, turn on “show input boxes”. Then use the GUI to insert a “definition” pattern. This inserts a node of type - - - “definition” into the syntax graph. The Visualizer draws the “:=” for it. - - - The red boxes indicate where “inputs” to a pattern go, which are children of the syntactic-entity (syntactic-pattern) in the syntax graph. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Fill in the rest of the text and input variable names. - - - Use GUI to fill in the “term ==” limit, with “t” - - - Will later add things to RHS that, when this pattern is used, will receive the values placed into the input-variable- - - - name positions. - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Here, a pattern has been added that applies a function to an input-value. This caused an extra level of - - - boxes to pop up, and parentheses to appear. The parentheses are part of the pattern that was just - - - inserted - - - The level of pattern that a particular input-box belongs to is indicated by the physical size of the box, - - - and the embedding.. that is why the LHS box got bigger when the RHS box did. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the second red box of the “...” pattern, and “+” is inserted via GIU. - - - The “...” pattern was defined to have a special Visualizer plug-in that replicates the red boxes, this is what causes - - - the “+” to appear where the corresponding black boxes used to be. - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The text typing is stopped, and instead the programmer performs a GUI gesture to add another child node, which is - - - an “input variable name” node, to the LHS-node of “:=”. This pops up a red box, into which the variable name - - - will be typed. In the syntax graph, this causes one child node, the “Taylor of” text to end, and a new child - - - node, an “input variable name” node, to be inserted. - - - Notice that the GUI knows the type of syntactic node that the insertion point is in, and only allows inputs valid for - - - that kind of node (hence, cannot type raw text into, say, the box where “+” is right now.. the GUI only allows - - - putting binary operators into that box) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the input-variable-name box, and “F” is typed as the name. In the syntax-graph, - - - the insertion-point was at the input-variable-name node, which has the property that the variable-name value is - - - an integer that looks up the text in the srcHolder's data-base (hash table for now). - - - When the typing is finished, the “F” will be saved in the data base and it's lookup-int placed into the property- - - - value of the property node hung off the “input-variable-name” node - - - - - - - - Drawing - - - - - - Next, insertion point is moved to RHS box, and the “...” pattern is inserted via GUI. - - - - - - Only the first boxes of the “...” are red, the black ones get filled in by the pattern itself, inside the Visualizer - - - The “term” is a variable that comes with the “...” pattern, and indicates the position within the pattern. This - - - variable is available via the GUI to patterns embedded within the “...” pattern. - - - The “term ==” is the end-expression. Any var-name that has an integer value that is calculated during the - - - construction of the terms, or a constant integer, can go into the red box. Notice, the type checking has an - - - extra level of work here.. it has to know that calculation happens after the final pattern has been placed onto - - - a worksheet. It has to figure out the result-type of that post-placement calculation. - - - - - - - - Drawing - - - - - - This is the Visualization when the “show input boxes” is turned off - - - for this definition in the GUI. IE, the Visualizer can draw this - - - pattern either with the input-boxes drawn, as shown below, or - - - without, as shown here. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - The insertion point is moved into the verbatim text box and “Taylor of” is typed in. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the LHS box of the “:=” pattern, and a “verbatim text” node is inserted via GIU. - - - This kind of node has text typed into it during definition of the pattern, and when the final pattern is placed - - - onto a worksheet, the text displays verbatim, for the programmer to see. This text has no function other than - - - being useful to the programmer.. in some sense, it is analogous “keywords” in other languages. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - Here's how the Taylor expansion is going to be used in end-code: - - - First, the programmer right-clicks at some point on a worksheet, which pops up the first of a sequence of menus. Each - - - menu entry has one o f the left-hand home-position keys as its short-cut. Choosing a menu entry causes another - - - menu to pop up, also with left-hand home-position keys as its short-cuts. - - - Finally, a menu will be reached that has “Insert Taylor Expansion” as one if its entries. Hit the key for that, and its - - - pattern will appear on the worksheet where the mouse right-click was originally performed. (There will also be - - - cursor-movement keyboard commands, so one never has to touch the mouse if one doesn't want to..) - - - Here is what the inserted Taylor pattern looks like: - - - This worksheet view will be seen when a person is viewing the OS instance. A worksheet is a processor placed into a system of processors, that has "below" it a numberof additional processors that are created and connected by using the worksheet. In effect, a worksheet is a GUI-helper for writing programs. It provides a programmerfriendly visualization of a system of processors, and provides a convenient way to create and connect new processors. Each line seen here is a visualization of a processorcreated by using this worksheet. The first two lines are visualizations of syntax trees held in srcHolders, and the last four (five) visualize processors plus their outputs. - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Once all the red input boxes have been filled in with valid entries, the black box will turn into the result of the - - - expansion. The result will be source on the worksheet, just like any other source on it. This source can be - - - attached to data-channels the same way other source is, which causes a live processor to be made from it. This - - - processor will compute on data that comes into the input data-channels, and produce results on its output - - - channels. - - - - - - - - Drawing - - - - - - Here's how to define the Taylor expansion. When the definition is done, it will look like this: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The function application has been filled in by using the GUI to choose to insert input-variable-names - - - from the LHS-node of “:=”. When get to implementation, this process for indicating that the - - - thing inside the box on the RHS is indicating a communication from the input-port on the LHS, - - - might change.. might make the Modifier recognize the variable name is the same, or make the - - - srcHolder make name-spaces for each level of embedding of patterns and do a search among - - - those name-spaces to match variable-names typed in to the RHS, or who knows what.. - - - - - - - - Drawing - - - - - - An interesting question here is “going backwards” during re-write.. for most definitions, either the LHS or the RHS can be matched, and the opposite side substituted in, or even missing elements inferred.. - - - for example, in use, get the arrow, with pre-Taylor on left and post-Taylor on right. What if don't fill in some of the spots on the LHS, and cut-and-paste and expression to the RHS that has some of - - - the boxes filled in that are receivers of inputs from the LHS. Then, there is the information available to infer what has to go in the input-boxes on the LHS, and to fill in the rest of the RHS expression.. - - - in fact, want it to propagate backwards.. so, say the “F” in the LHS was not complete, and the expression pasted into the RHS filled in the missing pieces.. the would want the inferred missing parts of - - - the “F” to propagate backwards all the way up through the worksheet, modifying every ancestor by filling in the missing pieces.. or maybe even asserting that the arrow had to be consistent and forcing - - - changes to the “F” that way, to propagate backwards to ancestors on the worksheet.. - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - This “...” has to pile up right-input operators.. including CONNECTING the sub-expression on the right as the input to the operator to its immediate left. Thinking, if do this, going to need a library of “...” - - - operators that do different things.. this “...” is special because it is a srcManipulation operator. This means the “...” has to include behavior about the syntax graph.. it has to hook nodes in the syntax - - - graph together each time it expands.. this one is specifically for replicating an operator.. so there is one kind of “...” for replicating right-input unary operators, one for replicating left-input unary - - - operators.. and a separate one for replicating binary input operators.. the binary input “...” has the behavior that it manipulates the syntactic-graph such that it connects each middle-term to BOTH - - - binary operators that bound it.. hmmm.. should make it a nesting instead? Need to think about consequences.. implications for parallelism and whatnot.. - - - Yes, keep it as truly binary.. the inputs are attached via links.. have a left-input link and a right-input link.. the target of the left-input link of one binary operator is the same as the target of the right-input - - - link of the neighboring binary operator. The semantics of how the result gets computed is up to the re-writer and the Translator.. There is no loss in making it symmetric, but in contrast there is a - - - constraint that must be “undone” if make it a nesting.. leaving it symmetric leaves the choice of order free from a syntax graph point of view.. the order will be decided by properties attached to the - - - binary operator.. these will be order of application properties - - - Also want to revisit visualizing the “...” pattern.. will have to have special code just for it, because the visualized form does not match the syntax-graph form.. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - This is the pattern for the kind of “...” that replicates a right-input operator. This pattern is specific to right-input unary operators being NESTED, so it knows that there is only one input to the right-most - - - operator, and the rest of the replication is the operator applied to the result of previous applications. Thus, the right-most red box is the thing the right-most operator is applied to. - - - Visualization, to be like the equation wrote above, the way want it, will have to, in effect, perform the operation of “...” somehow during visualization.. will have some kind of thing attached to the “...” - - - operator that the Visualizer invokes that generates a syntax-graph that it gives to the Visualizer. That syntax graph is the one Visualized. - - - See complications with embedding, perhaps, but maybe not if keep structure of these VisualizationGenerators clean.. might be able to get generators inside of generators to come out right.. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - Here, the “term” was gotten by using the GUI.. using right-click menus, selected the “internal” variable from one of the other patterns (the top level “…” pattern) and caused it to be inserted in the input- - - - variable-name box of this “…” pattern. The VisualizerGenerator for this “…” will substitute whatever expression ends up in the input-box for “term ==”, which represents the final term. This means that - - - when the GUI selects the internal variable “term” then there has to be some kind of connection by which the VisualizerGenerator can ask for the end-expression of that internal variable.. the variable has - - - to be of a type that the VisualizerGenerator knows it has an end-expression.. so, maybe, make “…” something that the VisualizerGenerator can query? Or, make some kind of hook or something come - - - with the GUI selection.. maybe the GUI inserts something into the syntax-graph.. or maybe “term” has a property attached.. yes, of course.. give it a property that all VisualizerGenerators look for.. - - - something like “has an end-expression” together with property whose value is the hook to get end-expression or ask for that end-expression. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - term-1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - term-1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Wiggling around here, trying to figure out how to do the replicating derivative thing.. This is - - - something like what want to figure out.. Need some kind of “...” that can replicate a right- - - - input operator the number of times indicated by a value that is input to the “...”. - - - - - - - - Drawing - - - - - - The red box on the right is the input to the right-most replicated right-input operator.. : ) - - - Nailed it. This is what wanted.. so, build up the input-expression inside the box. - - - - - - - - Drawing - - - - - - Added the application of the “F” input to the “x0” input into the box - - - - - - - - Drawing - - - - - - Added the multiply of the F-to-x0 result by the contents of the - - - empty red-box - - - - - - - - Drawing - - - - - - Added a “-” operator, and placed it inside an - - - “exponentiate” operator, and used GUI to grab - - - input-variables “x” and “x0” and grab the internal - - - “term” variable from outer-most “...” – by the - - - way, will have another custom Visualizer plug-in - - - for exponentiate - - - - - - - - Drawing - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - The separately built part has been cut and pasted into the full expression. - - - May have some trouble here with visualization.. the “term” in the deriviative “...” expansion has to be substituted with “2” and then executed to generate the single derivative in the second position.. the - - - value “2” has to be gotten from the outer-most “...” pattern.. communication has to happen during the visualization process, where the Visualizer plug-in that is generating the sub-graph for the derivative - - - “...” gets a value for replicating from the outermost “...” pattern, to replace the “term” value that comes from the outer-most “...” pattern. - - - Also, the “term-1” in the exponent has to communicate with the outermost “...” during visualization of the outermost “...”.. so the outermost “...”'s the one controlling the sending of the “term” value to the - - - internal visualizer plug-ins that receive its “term” variable value. - - - Finally, the exponent has to visualize in a special way.. it is a binary operator, but it visualizes in the way exponents do.. also, when the exponent value is “1” during visualization, it doesn't display at all. - - - The last term of the outermost “...” might go ahead and send the “t” in to the expression, in which case the derivative “...” would expand.. but that's a visualizer implementation thing.. or, more precisely, a - - - visualizer plug-in thing.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - z - - - - - - - - + - - - - - - - - Jacobian(z) - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - z - - - - - - - - about - - - - - - - - - - - - - - 1.213 - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - 4 - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - <pattern - - - - - - - - ( - - - - - - - - t - - - - - - - - ) - - - - - - - - > - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) - - - - - - - := - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - z + - - - - - - - - Jacobian - - - - - - - ( - - - - - - - - z - - - - - - - - ) - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - z - - - - - - - - about - - - - - - - - - - - - - - 1.213 - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - 4 - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - <pattern > - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - make H( - - - - - - - - t - - - - - - - - ) into a processor - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - = - - - - - - - 8.915 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - <processor "H( t )"> - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) = {2.14, 3.919, .. 21.78} - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - = - - - - - - - {1,2 .. 20} - - - - - - - - Drawing - - - - - - - - - - - Drawing - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - A - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - =:= - - - - - - - - Drawing - - - - - - In Hamiltonian path, get a graph.. so - - - have graph data structure - - - Have a root of the graph. - - - have neighbor of each node - - - Q: how to define a data structure? What does it look - - - like? - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - GraphNode - - - - - - - - Drawing - - - - - - nodeValue: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - neighbors: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - 1 - - - - - - - - Drawing - - - - - - N - - - - - - - - Drawing - - - - - - int - - - - - - - - Drawing - - - - - - GraphNode - - - - - - - - Drawing - - - - - - GraphNode - - - - - - - - Drawing - - - - - - Notice that defining a data structure is syntactic sugar for - - - defining a processor. Creating an instance of a data - - - structure is the same as creating a processor. One passes - - - the source for the data-structure to the creator. A data - - - structure definition has implied commands, one to access - - - each element. - - - Other thing is that one doesn't have to define the type of - - - the contents of fields.. the type will be inferred by use.. if - - - it can't be inferred, then the programSpace causes an - - - interaction with the Display and the programmer is asked - - - to fill in. - - - - - - - - Drawing - - - - - - g G - - - - - - - - - - - - - - - - : neighbors - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← - - - - - - - - Gin - - - - - - - - , nodesInPath ← [], graphSize ← - - - - - - - - Gin - - - - - - - - .giveSize - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Drawing - - - - - - The “ . . “ represents a set. The numbers up above - - - indicates that it is an ordered set. The “GraphNode” - - - inside means that each element is of type - - - GraphNode. The “ . . “ is a pattern that was inserted - - - via the GUI - - - - - - - - Drawing - - - - - - So, get a graph-node.. want to explore each neighbor. If do recursively, then - - - saying either that are doing creation of a new processor while running, or are re- - - - using the same processor and passing it a new set of name-space tunnels. - - - - - - Either way, what want to do is have some notion of path or some notion of - - - nodes visited.. Thinking represent path as a set of the nodes visited. - - - - - - There are performance issues here.. the less say the more sophisticated the - - - specializer has to be to get good performance.. the more say the more get in the - - - way of specializers for some hardware. So, if use a primitive that works on just - - - a set, saying less than if use a primitive that works on an ordered set, of the - - - nodes of the graph visited so far.. - - - - - - Start with unordered set.. receive a node in.. want to say that if the node in is - - - an element of the previously visited nodes then dead-end.. otherwise, if the size - - - of the set is equal to number of nodes in graph, then found soln and - - - communicate it out. - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - nodesInPath - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - doNothing - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - nodesInPath : size = = graphSize - - - - - - - - Drawing - - - - - - Set is a primitive processor type of EQNLang.. it has a size field that is defined - - - with an invariant, that it always contains the count of the number of elements in - - - the set - - - - - - Having invariants among fields in a processor is a feature of EQNLang. Any - - - processor that has fields can define invariant relationships among those fields. - - - When such an invariant exists, there can be dependent fields that get automatically - - - updated, or there can be co-equal fields. In the case of co-equal fields, read access - - - is turned off when the invariant is not satisfied. - - - - - - Access to fields is a command sent to a processor, so there can be different kinds - - - of access. The visual may look the same, but when access is to a field that is part - - - of a co-equal invariant, then there is automatically the ability for the processor to - - - send back an “invariant not satisfied” value (??) (in most implementations, this - - - will only come back after the requesting processor has been waiting too long, for - - - example to acquire a lock, and has timed out). - - - - - - The requesting processor can define a handler for this, similar to a try-catch - - - block in Java.. or it can let the exception propagate.. seeing an exception system - - - as in Java.. except just attach the handler, don't see it in the main flow of the - - - code. - - - - - - - - Drawing - - - - - - size == N - - - - - - - - Drawing - - - - - - invariant - - - - - - - - Drawing - - - - - - addNeighbor - - - removeNeighbor - - - - - - - - Drawing - - - - - - In fact, a data structure in EQNLang is essentially the - - - same thing as an object in OO languages. - - - The functions that the memory processor can perform are - - - stated inside the data structure, but defined outside on the - - - same worksheet. - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - - output - - - - - - - - ← nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - output - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← g, nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - Notice a few things happening here: a namespace is being explicitly controlled. There is a namespace-entries-creation at the top - - - that that has “G”, “nodesInPath”, and “graphSize” in it. The “G” is set from “Gin”, which is bold and italic indicating that it - - - becomes whatever is placed in the input position (inside parens here). The name in the “Gin” position names a processor in the - - - namespace that the “H” processor instance finds itself in. (IE, this source is used to make a processor, which is placed into a - - - namespace. The source-name put in the “Gin” position is attached to a processor in that same namespace. If code is placed in - - - the input-position then a name is generated for that code, or else a larger processor is made that combines the “input” code with - - - the “H” code stated here. It is up to the Translator to decide which it wants to do. - - - - - - Notice also the use of the switch construct.. the values on the left of the bar are matched against the result of the expression. - - - The box is replaced by whatever code is to the right of the value that matches the expression result. - - - - - - Just an aside, notice that comparison operators are actually pattern detectors.. they can be considered to check whether the - - - input satisfies a property criteria. The “greater than” property, the “same as” property, etc. There is a difference between the - - - property and the operator that examines an input to determine if it has that property. - - - - - - Notice that the recursion states that the same KIND of processor is given a new namespace.. remember, this is source code, so - - - the arrow is part of source and points to source.. different symbols would be used if one wanted to state that a particular - - - instance of a processor spec were to receive the name-space tunnels created. Only memory processors have internal state, so - - - they're the only kind of processor that it matters which instance one uses to perform a calculation.. for all other processors, it - - - only matters which name-space tunnels it is given.. - - - - - - the dot-dash lines indicate creation of name-space tunnels that are passed to the instance of the processor created from the - - - pointed-to spec. In the case above, a tunnel is made for “G”, “nodesInPath”, and “graphSize”. Whatever source the “H” - - - appears in determines the processor that gets assigned to “G”. The “Gin” is a source-level name, not a processor level name. It - - - indicates lookup in the srcHolders. The “Gin” in the code here has two meanings: anything that appears in that position is - - - inserted into the other side (of the =:=) when re-write is done.. and the other meaning is “Gin is assigned to some expression in - - - the source name-space, by virtue of pattern-matching to the position Gin appears in the definition-source and whatever is in that - - - position in the use-source”.. so the “G ← Gin” means “when a processor is made from a use-of-H-source, make G lookup the - - - same processor as (whatever Gin got assigned to in the source) looks up, now that a processor has been made from that use-of- - - - H-source” - - - - - - The output thing is a bit weird.. the idea is that if the use-of-H appears in an input position, then that input receives H's - - - output, which is represented by “output”.. alternatively, it isn't done consistently here, but had the notion that there could be - - - some way to specify in the use-of-H a name (variable) in that use's source name-space that got assigned to whatever processor - - - output gets assigned to inside of the H-processor. (which would be the nodesInPath processor that got created up at the top) - - - - - - Up at the top, the “ ← []” causes the creation of a new, empty, “set” mem-processor. This happens each time whatever G - - - ended up being copied from changes its contents. IE, if it gets assinged to a different processor, or if the current processor - - - changes it's data contents. This is the semantics I am choosing for EQNLang.. for now.. seems a bit risky with “notification” - - - issues.. - - - - - - Another syntactic-sugar thing, that might be risky for optimization, is the “graphSize” automatically remains in the name- - - - space when the recursive call is made.. - - - - - - this means that an optimizer is going to have to figure out that it has to copy this value to all instances of the H processor it - - - makes.. and it's going to have to figure out that all it has to do to parallelise this code is run it for a short time, breadth-first, - - - making a copy of each nodesInPath each time the add is done.. then it can distribute those copies to different instances of the H - - - processor. - - - - - - This can be figured out from looking at the name-space tunnel creation inside the dot-dashed boxes, and looking at how those - - - names are used. - - - - - - Also, the “g” on the one arrow is just a comment.. the “ for all __ is an element of” is a single pattern.. it assigns “g” to the - - - processors that are inside the set, then passes the resulting name-space tunnel to - - - - - - - a - - - - - - - processor created from the source pointed to. - - - This means that multiple instances of the spec can be created, and a different assignment given to each. - - - - - - The second use of “element of” is a property-checker.. this is a different thing that is pulled down from the GUI.. it results in - - - “yes, an element of the set matches the input element” or “no” - - - - - - Notice that, when parallelism is done, the nodesInPath will have to be copied.. but because nodesInPath is in a name-space - - - tunnel and not inside the H processor it is safe to copy the nodesInPath once for each copy of the H processor created.. because - - - it is passed in, there is no parallelism hazard with modifiying it inside, as long as it is passed back to the same H-instance that - - - did the modifying.. Hmmm, not sure that's even required.. but if more than one mem-processor that were passed in are - - - modified inside, then either need semantics to say whether they have to be kept correlated, or else have to always keep them - - - correlated.. Ahhh.. because the invocation of the H processor starts with a clean assignment to nodesInPath, know that no - - - other processors anywhere else are modifying the same mem-processor that is retrieved by “nodesInPath”. That's the key.. a - - - single invoking input creates a fresh mem-processor, thus giving processors made from this source complete control of the - - - mem-processor. - - - - - - - - Drawing - - - - - - ( - - - - - - - - Gin - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - nodesInPath.add( g ) - - - - - - - - Drawing - - - - - - - A - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - =:= - - - - - - - - Drawing - - - - - - g G - - - - - - - - - - - - - - - - : neighbors - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← - - - - - - - - Gin - - - - - - - - , nodesInPath ← [], graphSize ← - - - - - - - - Gin - - - - - - - - .giveSize - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Group - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - nodesInPath - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - g - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - doNothing - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - nodesInPath : size = = graphSize - - - - - - - - Drawing - - - - - - true - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - false - - - - - - - - Drawing - - - - - - - output - - - - - - - - ← nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - output - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - Drawing - - - - - - G ← g, nodesInPath - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - Gin - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - nodesInPath.add( g ) - - - - - - - - Drawing - - - - - - ToDo make a figure, out of the above components, that shows a data-structure visually, and shows a “generic kernel” - - - on that structure.. with an equation attached to one element of the structure, and arrows pointing to neighboring - - - elements.. each arrow points to one of the inputs to the equation. - - - A preTranslateSrcManipulator is defined as a standard thing that runs before the re-writer and before translation to - - - machine form. This generic kernel syntax is an input to a plug-in written for the preTranslateSrcManipulator.. - - - the plug-in translates the syntax into something the re-writer understands.. the re-writer is itself a plug-in to the - - - preTranslateSrcManipulator, but it runs last.. - - - Brings up issues about order of plug-ins running.. but that's actually not an issue.. because there is an ordering defined - - - by the syntax graph.. the outer-most are run first.. then any syntax that was inside (either inside a node, or lower - - - down in the syntax tree) is inspected to see if it needs a srcManipulator run on it. - - - BTW, using the notion of “levels” of syntax graph.. the architecture thing, where have architecture levels, where each - - - node of the architecture syntax graph has inside the node, as the node-value an entire graph, which is a sub-graph - - - of a lower-level syntax-graph.. so, can define srcManipulator plug-ins that use this “sub-graph inside a node” - - - thing.. the src manipulator can be written to take the sub-graph and copy it or modify it and connect it in - - - appropriately to the graph the above-node was inside of. - - - For the transform system, the pre-srcManipulated entities have properties attached, and the post-src-manipulated - - - syntactic elements retain properties that link them together as a single syntactic unit.. so the transform system - - - has this pre-manipulation structure, with its properties, available to it.. - - - This allows easy identification of dependency patterns of a generic kernel operating on a parameterized data-structure. - - - And, it keeps all the code of the kernel together in one piece.. so, a divider of the data should be reasonable to - - - define for such generic kernel syntax.. it has to respect the dependencies, that is existent already, compilers - - - understand dependencies and do code transformations based on them.. such a divider-generator would also have - - - to understand side-effects.. that would be built in to the syntax.. it would have to indicate a state-change order.. - - - which is another dependency, in time.. - - - So, have dependencies in space and dependencies in time.. the iteration space is automatically generated from this.. - - - Last thing need is to include syntax that states allowed communication patterns when memory processors are used for - - - communication (side effect). The allowed communication patterns are specified by showing the same kinds of - - - arrows going from statements that generate the result to the memory processor type that receives, then - - - - - - - linked - - - - - - - - - - arrows going to the places that are - - - - - - - allowed - - - - - - - to receive.. this syntax doesn't state that such communication is - - - required, only that it is allowed.. the actual communication operations that carry out the action are specified - - - elsewhere, and state only the memory processor type, and (probably) a reference to the definition of the allowed - - - patterns. - - - This scheme is equivalent to channels in middle-ware.. each channel comes with rules for readers and writers and - - - broadcast.. but this scheme is more flexible on communication patterns.. it can allow complex rules on the - - - allowed patterns.. - - - Note, multiple kinds of names.. just thinking about this.. have names that are in the srcHolder name spaces, and names - - - that are in the created processor name-spaces.. that's the difference between functional languages and imperative - - - ones.. all names in a functional language are in the srcHolder name-space (except recursive, which are sort of - - - also because they cause creation on the fly of new processors from src, in effect.. come back to this later and - - - look closely at it).. however, the name in the source of a memory processor becomes a name in the name-space - - - of the created processors.. in functional, everything refers to srouce.. it all names a shape of processors to be - - - created.. none of the names in a functional ever exist verbatim in the created processor's name spaces (? really.. - - - look closely).. anyway, they never name a specific instance of a processor.. that's the key difference.. when - - - have the name in the source of a specific instance of a processor, then can hand that name to other processors, - - - creating name-space tunnels.. that's the issue.. that's what allows side-effects, and what eliminates the ability to - - - create different instances in different places.. in function just say the shape of processor, not the specific - - - instance of a created one.. so, can always create multiple ones of the same shape and give different – what do I - - - call these? The “context” the pairing of source-names to data-values.. it's a name-space.. but have to think - - - more about what is happening here.. look at the Hamiltonian picture, the dashed rounded boxes shown as inputs - - - are the things I want a name for.. the boxes are explicit syntax for manipulating name-spaces that are given to - - - processor instances, and added to that instance's own name-space.. it's like a tunnel-creation command.. - - - Ahh.. that's what they are.. a “value” is a processor that has specific data in it.. when we think about a “value” what we - - - picture is a memory processor instance that has a state-pattern inside it that we recognize.. the pattern for count, - - - like the integers, or the pattern for character, or the pattern for other “primitive” data type.. a primitive data type - - - is just a pattern of state that we humans have matching patterns for that we use very very often. We have chosen - - - the count pattern because it is used so very often.. We could choose any pattern as a primitive data type.. Float - - - is a model of the pattern we have in our heads that we have recognized in the world and very probably have as a - - - pattern that our very processing elements use in their own state evolution.. that is, neurons directly use - - - continuous numbers.. intensity in to eyes or ears, and my simulated systems I think about seem to work directly - - - in terms of continuous.. rather than logic thinking which uses sharp-edged patterns and jumps from one to the - - - next when required's match.. the rule-patterns are logic in action.. and all the inferences are them doing search - - - to figure out what has to be in order for necessaries to be satisfied for the known-to-be-there resultant to have - - - shown up on the end.. - - - This stuff above about srcManipulator plug-in for syntax graph had me jazzed about the everything-is-a-processor - - - abstraction.. that abstraction is what makes everything here so easy to do and possible to keep things straight.. - - - the difference between srcHolder operations and operations of processors created from contents of srcHolders.. - - - was thinking this is the breakthrough, the key, that will enable human-like processing behavior.. we have the - - - pattern generation from raw details (k-means), and we have search (branch and bound.. chess).. the missing - - - piece is the rule-patterns, and the construction of the system that has all the parts that people have.. the goal - - - system, the pattern-generation.. the pattern-search.. pre-visualization.. and so forth.. the goal system is, of - - - course, our emotional machinery.. with rule-patterns like this, that can be run backwards, plus search, and the - - - source for the patterns held inside processors that can modify the patterns ACCORDING TO THE PATTERNS.. - - - that's the missing piece that can be filled in now. - - - The last thing that's left is the continuous-system stuff.. the things I do where I imagine a dynamic system running and - - - watch what it does.. that gives me predictions, is how I understand mechanical things.. sort of.. there's - - - fundamental in there.. there's the state-tree thing of identifying patterns that simplify larger ones down to less - - - total state.. (notes from the digital design lab taught at UCSC).. anyway, don't quite have a handle on that type - - - of thinking yet, as far as making something that works that way.. perhaps just fuzifying the rule-patterns will do - - - it.. hmmm.. something to think about.. the neurons make the sharp-edges patterns out of continuousness.. so, - - - yeah, find something that has varying degress of fuzyness.. turn down the fuzy to get the sharp edged.. turn it up - - - to get simulated system? Sort of flows along rather than jumping to one stable side or the other.. the neurons - - - learn the flow.. they receive the flow from observation, and generate a setting that matches it.. then can give - - - new inputs to the flow system and watch it flow, see where it goes..? Something like that maybe.. point is - - - something that has features of fundamental, of strength within competing dependent things all vying to set the - - - continuous-value.. oh yeah, the decision-making mechanism, forgot that one, where do the continuous multiply- - - - accumulates, to figure out benefit vs cost.. weighing desires along different chains of things that produce - - - strengths of input.. and have patterns that modify the strength according to kind of strength from other.. ie, “if - - - she's there, then I'll have a lot of flirt-fun, otherwise the best will be maybe intellectual talking with so and so - - - fun”.. or “vanilla together with chocolate syrup” vs “chocolate together with caramel syrup”.. the chocolate is - - - great by itself, the caramel is too, but together, not as great.. meanwhile vanilla good, choc syrup good, but - - - together, multiply the good.. that kind of direct rule-for-interaction-of-continuous.. where “good” is a - - - continuous thing.. amount the pleasure center is pricked.. and the vanilla good interacts with the choco syrup - - - good according to a particular learned pattern.. gained from experiencing the two together.. can do combos in - - - my mind that haven't done together before.. that's how I can come up with new recipe.. I imagine each in my - - - head, have the interaction rules in my head from experience, and imagine the components together.. that's how I - - - figured the duck recipe sent to Ozana.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Modifier - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - GUIGestureConverter - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Display - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Visualizer - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SyntaxGraph - - - - - - - - Drawing - - - - - - SrcHolder - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - Modifies - - - Directly - - - - - - - - Drawing - - - - - - Reads - - - Directly - - - - - - - - Drawing - - - - - - Modifier Command - - - - - - - - Drawing - - - - - - DisplayElement List - - - - - - - - Drawing - - - - - - GUIGesture - - - - - - - - Drawing - - - - - - Processor in Syntax - - - - - - - Four kinds of notation for “Processor” in the synatx: - - - -] Sharp-cornered boxes show spec of processor - - - -] Round-cornered dashed boxes show processor-spawner - - - -] Round-cornered solid boxes show already-created processor - - - -] On worksheet, “create processor” has “=>” with created processor on right - - - - - - - - Drawing - - - - - - Syntax that is Fixed - - - - - - - Some primitive parts of EQNLang have fixed pre-visualized-syntax that cannot - - - be overridden: - - - -] The syntx for the different kinds of processor (but can visualize differently) - - - -] The basic parts of a pattern - - - – - - - ]] Fact of having boxes - - - – - - - ]] Fact of placing something inside a box == communication - - - – - - - ]] Fact of being inside a box == rhs of bottom of semantic rule is inside box - - - – - - - ]] Fact of spawner being inside box == “out” port of spawned goes into box - - - -] The “From” and “Into” plus the arrows has fixed meaning - - - -] - - - - - - - - Drawing - - - - - - Processor Spawner - - - - - - - Rounded and dashed box represents a spawner. The Hamiltonian path program - - - is written as nested spawners. - - - -] A spawner accepts an environment as input - - - -] Each time a new environment arrives, a processor is spawned to consume it - - - -] Spawned processors have one or more output ports - - - – - - - ]] Outputs can be connected by Variable on a worksheet - - - – - - - ]] Single output called “output” is connected by default to containing box - - - – - - - ]] Outputs can be connected by letter-match to output ports on left of “:=” - - - – - - - ]] Outputs can be wired directly to input ports of other patterns - - - -] Spawned processor still has the - - - – - - - ]] Inputs can be connected by letter-match to param on left side of “:=” - - - - - - - - Line 1 shows placing a syntax tree on the worksheet. This syntax tree can be "grabbed" by using the GUI and used in other syntax trees or as inputs toprocessors. This is making a pattern by partially filling in a Taylor expansion.The "z" here was selected in the GUI to name an input box. The syntax treewas constructed to have a single input box, visualized each place it occurs inthe syntax tree as "z", and to have an instance of "Jacobian()" pattern, which takes one input, and an instance of Taylor pattern. The input is given to Jacobian, the result added to itself, then insertedinto the Taylor's first input-box. The input is also inserted into the Taylor'ssecond input box. The constant "1.213" goes into the Taylor's 3rd input, and"4" goes into its fourth. Notice that grammar checking of the Taylor's secondinput "with respect to z" happens when "z" gets filled in. - The second line shows making the pattern (syntax tree) defined onthe first line be the right hand side of a ":=". Here, the syntax treeis rooted with a ":=" node, with <function> as left-hand-side, wherethe function name is "H", verbatim, and it has one input-box, whichis named "t". The RHS has the LHS's input-box go to the input-box ofthe pattern defined in line 1. So, when this is used, for examplewith "H(2)" then the "2" will go to the input box of the pattern fromline 1 -- (and, grammar check will say that 2, an int, is not allowed!) - On line 3, the worksheet gets a worksheet variable "t" defined andgiven the value "8.915".. this, of course, is a different "t" than theone that names the input-box of the function-def on line 2. - On line 4, the "make <input box> into a processor" pattern is placedonto the worksheet. The function defined in line 2 is given the worksheet variable defined in line 3 and the combo is put into the<input box>, resulting in a processor. The resulting processor isvisualized as whatever it appeared as in the <input box> for the restof the worksheet. This processor takes the value of the worksheetvariable "t" as its input. Whenever "t" gets changed, the processorwill produce a new result value from t's new value. - IOn line 5, "t" is assigned values from 1 to 20, by putting a processoron the worksheet, visualized as " = { , , .. }", which producessuccessive assignments to the worksheet var that is named on theLHS of the =. - On line 6, a processor is put on the worksheet that visualizes on itsRHS the outputs produced by the processor named on its LHS. - To the left and anchored on the worksheet just slightly below, a processor is placedon the worksheet that visualizes the same outputs from the same "H(t)" processor,but in graph form - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Worksheet Foo - - Drawing - - - - - - - - - - - - - - - - diff -r b0de2e24054e -r 5c0400b5ae59 1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/Worksheets_and_defining_Taylor_expansion_process_better.svg --- a/1__Development/9__Design_documents/0__figures__on_which_work_out_fundamentals_of_EQNLang/Worksheets_and_defining_Taylor_expansion_process_better.svg Mon Dec 03 02:19:41 2012 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,23183 +0,0 @@ - - - - - - - - - - - image/svg+xml - - - - - - This worksheet view will be seen when a person is viewing the OS instance. A worksheet is a processor placed into a system of processors, that has "below" it a numberof additional processors that are created and connected by using the worksheet. In effect, a worksheet is a GUI-helper for writing programs. It provides a programmerfriendly visualization of a system of processors, and provides a convenient way to create and connect new processors. Each line seen here is a visualization of a processorcreated by using this worksheet. The first two lines are visualizations of syntax trees held in srcHolders, and the last four (five) visualize processors plus their outputs. - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - z - - - - - - - - + - - - - - - - - Jacobian(z) - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - z - - - - - - - - about - - - - - - - - - - - - - - 1.213 - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - 4 - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - <pattern - - - - - - - - ( - - - - - - - - t - - - - - - - - ) - - - - - - - - > - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) - - - - - - - := - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - z + - - - - - - - - Jacobian - - - - - - - ( - - - - - - - - z - - - - - - - - ) - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - z - - - - - - - - about - - - - - - - - - - - - - - 1.213 - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - 4 - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - <pattern > - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - make H( - - - - - - - - t - - - - - - - - ) into a processor - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - = - - - - - - - 8.915 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - <processor "H( t )"> - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) = {2.14, 3.919, .. 21.78} - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - = - - - - - - - {1,2 .. 20} - - - - - - - - Drawing - - - - - - - - - - - Drawing - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - - - - - - - - Drawing - - - - - - H( - - - - - - - - t - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Worksheet Foo - - Drawing - - - - - - - - - - - - - - - - Line 1 shows placing a syntax tree on the worksheet. This syntax tree can be "grabbed" by using the GUI and used in other syntax trees or as inputs toprocessors. This is making a pattern by partially filling in a Taylor expansion.The "z" here was selected in the GUI to name an input box. The syntax treewas constructed to have a single input box, visualized each place it occurs inthe syntax tree as "z", and to have an instance of "Jacobian()" pattern, which takes one input, and an instance of Taylor pattern. The input is given to Jacobian, the result added to itself, then insertedinto the Taylor's first input-box. The input is also inserted into the Taylor'ssecond input box. The constant "1.213" goes into the Taylor's 3rd input, and"4" goes into its fourth. Notice that grammar checking of the Taylor's secondinput "with respect to z" happens when "z" gets filled in. - The second line shows making the pattern (syntax tree) defined onthe first line be the right hand side of a ":=". Here, the syntax treeis rooted with a ":=" node, with <function> as left-hand-side, wherethe function name is "H", verbatim, and it has one input-box, whichis named "t". The RHS has the LHS's input-box go to the input-box ofthe pattern defined in line 1. So, when this is used, for examplewith "H(2)" then the "2" will go to the input box of the pattern fromline 1 -- (and, grammar check will say that 2, an int, is not allowed!) - On line 3, the worksheet gets a worksheet variable "t" defined andgiven the value "8.915".. this, of course, is a different "t" than theone that names the input-box of the function-def on line 2. - On line 4, the "make <input box> into a processor" pattern is placedonto the worksheet. The function defined in line 2 is given the worksheet variable defined in line 3 and the combo is put into the<input box>, resulting in a processor. The resulting processor isvisualized as whatever it appeared as in the <input box> for the restof the worksheet. This processor takes the value of the worksheetvariable "t" as its input. Whenever "t" gets changed, the processorwill produce a new result value from t's new value. - IOn line 5, "t" is assigned values from 1 to 20, by putting a processoron the worksheet, visualized as " = { , , .. }", which producessuccessive assignments to the worksheet var that is named on theLHS of the =. - On line 6, a processor is put on the worksheet that visualizes on itsRHS the outputs produced by the processor named on its LHS. - To the left and anchored on the worksheet just slightly below, a processor is placedon the worksheet that visualizes the same outputs from the same "H(t)" processor,but in graph form - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Group - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - To build the pattern for Taylor expansion, turn on “show input boxes”. Then use the GUI to insert a “definition” pattern. This inserts a node of type - - - “definition” into the syntax graph. The Visualizer draws the “:=” for it. - - - The red boxes indicate where “inputs” to a pattern go, which are children of the syntactic-entity (syntactic-pattern) in the syntax graph. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Fill in the rest of the text and input variable names. - - - Use GUI to fill in the “term ==” limit, with “t” - - - Will later add things to RHS that, when this pattern is used, will receive the values placed into the input-variable- - - - name positions. - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Here, a pattern has been added that applies a function to an input-value. This caused an extra level of - - - boxes to pop up, and parentheses to appear. The parentheses are part of the pattern that was just - - - inserted - - - The level of pattern that a particular input-box belongs to is indicated by the physical size of the box, - - - and the embedding.. that is why the LHS box got bigger when the RHS box did. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the second red box of the “...” pattern, and “+” is inserted via GIU. - - - The “...” pattern was defined to have a special Visualizer plug-in that replicates the red boxes, this is what causes - - - the “+” to appear where the corresponding black boxes used to be. - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The text typing is stopped, and instead the programmer performs a GUI gesture to add another child node, which is - - - an “input variable name” node, to the LHS-node of “:=”. This pops up a red box, into which the variable name - - - will be typed. In the syntax graph, this causes one child node, the “Taylor of” text to end, and a new child - - - node, an “input variable name” node, to be inserted. - - - Notice that the GUI knows the type of syntactic node that the insertion point is in, and only allows inputs valid for - - - that kind of node (hence, cannot type raw text into, say, the box where “+” is right now.. the GUI only allows - - - putting binary operators into that box) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the input-variable-name box, and “F” is typed as the name. In the syntax-graph, - - - the insertion-point was at the input-variable-name node, which has the property that the variable-name value is - - - an integer that looks up the text in the srcHolder's data-base (hash table for now). - - - When the typing is finished, the “F” will be saved in the data base and it's lookup-int placed into the property- - - - value of the property node hung off the “input-variable-name” node - - - - - - - - Drawing - - - - - - Next, insertion point is moved to RHS box, and the “...” pattern is inserted via GUI. - - - - - - Only the first boxes of the “...” are red, the black ones get filled in by the pattern itself, inside the Visualizer - - - The “term” is a variable that comes with the “...” pattern, and indicates the position within the pattern. This - - - variable is available via the GUI to patterns embedded within the “...” pattern. - - - The “term ==” is the end-expression. Any var-name that has an integer value that is calculated during the - - - construction of the terms, or a constant integer, can go into the red box. Notice, the type checking has an - - - extra level of work here.. it has to know that calculation happens after the final pattern has been placed onto - - - a worksheet. It has to figure out the result-type of that post-placement calculation. - - - - - - - - Drawing - - - - - - This is the Visualization when the “show input boxes” is turned off - - - for this definition in the GUI. IE, the Visualizer can draw this - - - pattern either with the input-boxes drawn, as shown below, or - - - without, as shown here. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - - - - - - - - := - - - - - - - - Drawing - - - - - - The insertion point is moved into the verbatim text box and “Taylor of” is typed in. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The insertion point is moved to the LHS box of the “:=” pattern, and a “verbatim text” node is inserted via GIU. - - - This kind of node has text typed into it during definition of the pattern, and when the final pattern is placed - - - onto a worksheet, the text displays verbatim, for the programmer to see. This text has no function other than - - - being useful to the programmer.. in some sense, it is analogous “keywords” in other languages. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - - - - - - - - - for - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Once all the red input boxes have been filled in with valid entries, the black box will turn into the result of the - - - expansion. The result will be source on the worksheet, just like any other source on it. This source can be - - - attached to data-channels the same way other source is, which causes a live processor to be made from it. This - - - processor will compute on data that comes into the input data-channels, and produce results on its output - - - channels. - - - - - - - - Drawing - - - - - - Here's how to define the Taylor expansion. When the definition is done, it will look like this: - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - The function application has been filled in by using the GUI to choose to insert input-variable-names - - - from the LHS-node of “:=”. When get to implementation, this process for indicating that the - - - thing inside the box on the RHS is indicating a communication from the input-port on the LHS, - - - might change.. might make the Modifier recognize the variable name is the same, or make the - - - srcHolder make name-spaces for each level of embedding of patterns and do a search among - - - those name-spaces to match variable-names typed in to the RHS, or who knows what.. - - - - - - - - Drawing - - - - - - An interesting question here is “going backwards” during re-write.. for most definitions, either the LHS or the RHS can be matched, and the opposite side substituted in, or even missing elements inferred.. - - - for example, in use, get the arrow, with pre-Taylor on left and post-Taylor on right. What if don't fill in some of the spots on the LHS, and cut-and-paste and expression to the RHS that has some of - - - the boxes filled in that are receivers of inputs from the LHS. Then, there is the information available to infer what has to go in the input-boxes on the LHS, and to fill in the rest of the RHS expression.. - - - in fact, want it to propagate backwards.. so, say the “F” in the LHS was not complete, and the expression pasted into the RHS filled in the missing pieces.. the would want the inferred missing parts of - - - the “F” to propagate backwards all the way up through the worksheet, modifying every ancestor by filling in the missing pieces.. or maybe even asserting that the arrow had to be consistent and forcing - - - changes to the “F” that way, to propagate backwards to ancestors on the worksheet.. - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - F - - - - - - - - ( - - - - - - - - x0 - - - - - - - - ) ( - - - - - - - - x-x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - This “...” has to pile up right-input operators.. including CONNECTING the sub-expression on the right as the input to the operator to its immediate left. Thinking, if do this, going to need a library of “...” - - - operators that do different things.. this “...” is special because it is a srcManipulation operator. This means the “...” has to include behavior about the syntax graph.. it has to hook nodes in the syntax - - - graph together each time it expands.. this one is specifically for replicating an operator.. so there is one kind of “...” for replicating right-input unary operators, one for replicating left-input unary - - - operators.. and a separate one for replicating binary input operators.. the binary input “...” has the behavior that it manipulates the syntactic-graph such that it connects each middle-term to BOTH - - - binary operators that bound it.. hmmm.. should make it a nesting instead? Need to think about consequences.. implications for parallelism and whatnot.. - - - Yes, keep it as truly binary.. the inputs are attached via links.. have a left-input link and a right-input link.. the target of the left-input link of one binary operator is the same as the target of the right-input - - - link of the neighboring binary operator. The semantics of how the result gets computed is up to the re-writer and the Translator.. There is no loss in making it symmetric, but in contrast there is a - - - constraint that must be “undone” if make it a nesting.. leaving it symmetric leaves the choice of order free from a syntax graph point of view.. the order will be decided by properties attached to the - - - binary operator.. these will be order of application properties - - - Also want to revisit visualizing the “...” pattern.. will have to have special code just for it, because the visualized form does not match the syntax-graph form.. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - t - - - - - - - - -1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - This is the pattern for the kind of “...” that replicates a right-input operator. This pattern is specific to right-input unary operators being NESTED, so it knows that there is only one input to the right-most - - - operator, and the rest of the replication is the operator applied to the result of previous applications. Thus, the right-most red box is the thing the right-most operator is applied to. - - - Visualization, to be like the equation wrote above, the way want it, will have to, in effect, perform the operation of “...” somehow during visualization.. will have some kind of thing attached to the “...” - - - operator that the Visualizer invokes that generates a syntax-graph that it gives to the Visualizer. That syntax graph is the one Visualized. - - - See complications with embedding, perhaps, but maybe not if keep structure of these VisualizationGenerators clean.. might be able to get generators inside of generators to come out right.. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - Here, the “term” was gotten by using the GUI.. using right-click menus, selected the “internal” variable from one of the other patterns (the top level “…” pattern) and caused it to be inserted in the input- - - - variable-name box of this “…” pattern. The VisualizerGenerator for this “…” will substitute whatever expression ends up in the input-box for “term ==”, which represents the final term. This means that - - - when the GUI selects the internal variable “term” then there has to be some kind of connection by which the VisualizerGenerator can ask for the end-expression of that internal variable.. the variable has - - - to be of a type that the VisualizerGenerator knows it has an end-expression.. so, maybe, make “…” something that the VisualizerGenerator can query? Or, make some kind of hook or something come - - - with the GUI selection.. maybe the GUI inserts something into the syntax-graph.. or maybe “term” has a property attached.. yes, of course.. give it a property that all VisualizerGenerators look for.. - - - something like “has an end-expression” together with property whose value is the hook to get end-expression or ask for that end-expression. - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - term-1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - + - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - = = - - - - - - - - Drawing - - - - - - term - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - Taylor - - - - - - - - - - - - - - - - of - - - - - - - - F - - - - - - - - with - - - - - - - - - - - - - - - - respect - - - - - - - - - - - - - - - - to - - - - - - - - x - - - - - - - - - - - - - - - about - - - - - - - - - - - - - - - x0 - - - - - - - - for - - - - - - - - - - - - - - - t - - - - - - - - - - - - - - - terms - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - := - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - . - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - term-1 - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - Wiggling around here, trying to figure out how to do the replicating derivative thing.. This is - - - something like what want to figure out.. Need some kind of “...” that can replicate a right- - - - input operator the number of times indicated by a value that is input to the “...”. - - Notice that this pattern requires an active processor to be added tothe syntax tree itself -- the modification to the syntaxtree takes values from other portions of the syntax tree and constructsthe rest of the tree on the fly -- the number of derivatives is determinedby the value of "t" which gets filled in when the pattern is placed intoa larger "holding" syntax tree - - - - - - Drawing - - - - - - The red box on the right is the input to the right-most replicated right-input operator.. : ) - - - Nailed it. This is what wanted.. so, build up the input-expression inside the box. - - - - - - - - Drawing - - - - - - Added the application of the “F” input to the “x0” input into the box - - - - - - - - Drawing - - - - - - Added the multiply of the F-to-x0 result by the contents of the - - - empty red-box - - - - - - - - Drawing - - - - - - Added a “-” operator, and placed it inside an - - - “exponentiate” operator, and used GUI to grab - - - input-variables “x” and “x0” and grab the internal - - - “term” variable from outer-most “...” – by the - - - way, will have another custom Visualizer plug-in - - - for exponentiate - - - - - - - - Drawing - - - - - - - x - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - The separately built part has been cut and pasted into the full expression. - - - May have some trouble here with visualization.. the “term” in the deriviative “...” expansion has to be substituted with “2” and then executed to generate the single derivative in the second position.. the - - - value “2” has to be gotten from the outer-most “...” pattern.. communication has to happen during the visualization process, where the Visualizer plug-in that is generating the sub-graph for the derivative - - - “...” gets a value for replicating from the outermost “...” pattern, to replace the “term” value that comes from the outer-most “...” pattern. - - - Also, the “term-1” in the exponent has to communicate with the outermost “...” during visualization of the outermost “...”.. so the outermost “...”'s the one controlling the sending of the “term” value to the - - - internal visualizer plug-ins that receive its “term” variable value. - - - Finally, the exponent has to visualize in a special way.. it is a binary operator, but it visualizes in the way exponents do.. also, when the exponent value is “1” during visualization, it doesn't display at all. - - - The last term of the outermost “...” might go ahead and send the “t” in to the expression, in which case the derivative “...” would expand.. but that's a visualizer implementation thing.. or, more precisely, a - - - visualizer plug-in thing.. - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - ( - - - - - - - - x - x0 - - - - - - - - ) - - - - - - - - Drawing - - - - - - . . . - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - d - - - - - - - - Drawing - - - - - - - - - Drawing - - - - - - d - - - - - - - - x - - - - - - - - - Drawing - - - - - - term - 1 - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - t - - - - - - - - - Drawing - - - - - - ( - - - - - - - - - - - - - - - - ) - - - - - - - - Drawing - - - - - - - - - - - - - - - - - Drawing - - - - - - - F - - - - - - - - - Drawing - - - - - - - x0 - - - - - - - - - - - Here's how the Taylor expansion is going to be used in end-code:First, the programmer right-clicks at some point on a worksheet, which pops up the first of a sequence of menus. Each menu entry has one o f the left-hand home-position keys as its short-cut. Choosing a menu entry causes another menu to pop up, also with left-hand home-position keys as its short-cuts.Finally, a menu will be reached that has “Insert Taylor Expansion” as one if its entries. Hit the key for that, and its pattern will appear on the worksheet where the mouse right-click was originally performed. (There will also be cursor-movement keyboard commands, so one never has to touch the mouse if one doesn't want to..)Here is what the inserted Taylor pattern looks like: - Worksheets and Defining Taylor Series Expansion - - diff -r b0de2e24054e -r 5c0400b5ae59 mathapedia_meeting.wma Binary file mathapedia_meeting.wma has changed