|
Worksheet Abstractions
The Worksheet model is based on relationships between objects. These objects may be UI elements in a worksheet; these may also be representatives of real-world entities e.g. people, offices etc. or abstract entities e.g. transaction identifiers.
The relationships are embedded within a worksheet as facts and rules. Facts are direct encoding of relationships e.g. mary is the parent of bob, james is the parent of mary etc. Other relationships e.g. ancestor relation, may be more succintly (, and sometimes more naturally) expressed by leveraging existing relationships e.g. parent relation. Such relationships are encoded as rules in the worksheet.
As a user interacts with a worksheet, the set of the facts in the worksheet is updated. The consequence of these updates are computed through the rules in the worksheet. These consequences may potentially be reflected as changes to the worksheet's UI. From UI Interaction to Facts
Interacting with widgets in a worksheet's UI e.g. checkboxes, dropdown lists, radio buttons may potentially add new facts and delete old facts. Try interacting with the widgets below to see which facts get inserted and which facts are deleted.
Notes: - If you enable Autoquote option for text fields: text inputs and text areas, quotes will be added to the supplied text. Otherwise, the text fields will be unquoted - and only accept syntactically valid object identifiers (which start with numbers or lowercase alphabets).
- The only widgets missing in the list above are: buttons and simulation controls. These two specialized widgets don't directly insert or delete facts from a worksheet. Instead, clicking on these widgets requests the insertion of certain facts that trigger dynamic rules. For example, the Play button in simulation controls starts a synchronous clock - periodically requesting the insertion of the object tick. More on dynamic rules and these widgets coming soon!
This new notation is called the sentential form. For a given set of facts, there's a mechanical way of translating back and forth from the tabular representation.
To go from tabular representation to sentential form - for each row of the table, list out the columns separated by commas, enclose this listing with round brackets '(' and ')', and add the table name as a prefix. See below for an example.
From Facts to Changes in UI
There are special classes of facts whose effects are reflected in a worksheet's UI e.g. content, text color, background color, width, font-family and so on. One class of such facts are from a relation called style. The style relation takes three arguments. The first of these is a UI element. The second argument is the style e.g. color, background etc. The third argument is the value corresponding to the style e.g. red, blue, 200 etc.
Note that in the absence of quotes, the second argument i.e. the style argument must either be camel-cased (see https://google.github.io/styleguide/javaguide.html#s5.3-camel-case). The style argument may be any of the valid styles used in webpages. For a comprehensive listing of these styles, please refer https://www.w3schools.com/cssref/
Try enabling different styles in the following example, and see its effect on the textarea (identified as the object area) on the right.
Another class of facts whose effects are reflected in a worksheet's UI are from a binary relation called innerhtml. The first argument of the innerhtml relation is a UI element, and the second argument is the HTML content of the UI element. Note that quotes are stripped off from the second argument's value.
Understanding Rules. How do rules work?
Rules are used to define new relationships in terms of existing relationships, which may either be listed as facts (as you've seen before), or characterized using other rules. In the following, we'll walk you through rules that define the grandparent relation.
Suppose that the parent relation is encoded using the following facts. These facts are of the form parent(X, Y) and denote that X is the parent of Y.
Now, let's define the grandparent relation. Note that as per the above set of facts, james is a parent of mary, and mary is a parent of bob. Therefore, james is a grandfather of bob. The grandfather relationship between james and bob through mary can be captured using the following rule. grandfather(james, bob) :- parent(james, mary) & parent(mary, bob) In an abstract sense, if the fact parent(james, mary) and the fact parent(mary, bob) are present, then derive the fact grandfather(james, bob).
Note that listing all possible combinations of people in order to define the parent relation is extremely inefficient! An alternative is to use variables, which can assume different values. Encoding of the grandfather relationship using variables is as follows. grandfather(X, Z) :- parent(X, Y) & parent(Y, Z) The above rule reads as: If X is a parent of Y and Y is a parent of Z, then X is a grandparent of Z.
Run the simulation presented below to get an idea of the how the above rule computes the grandfather relation. At any point of time, you may choose to Pause the simulation, or Step through the derivation steps.
With spreadsheets, I never had to use sentential representations in formulas. Why introduce this new syntax in formulas - Do I need them?
Note that spreadsheets formulas are purely functional i.e. for every unique combination of values of their inputs, they have an unique output value. This is NOT the case with general relationships which be may be one-many e.g. the parent-child relationship.
You may argue that multiple values can be denoted using lists or arrays. The problem with using lists and other nested structures are two fold. A. Using lists doesn't allow you to capture every one-many relationship. For example, consider the following relationship - let's call it r. r(a1, b1, c1) r(a1, b2, c1) r(a1, b2, c2) r(a2, b1, c1) See if you can characterize the above relationship between the a's, b's and c's as a function using lists or other nested structure? Which of the a's, b's and c's are the inputs and which are the outputs? (Hint: Don't try too hard - this cannot be encoded as a function!)
B. To reason about elements of the nested stuctures you have to explicitly characterize how to unnest / loop over these structures - at which point, the rules are no longer declarative.
To encode such relationships, the sentential form used to represent facts and rules is ideal.
Okay fine! I understand why formulas looks different now. Why can't I use If ... Then ... Else as used in Spreadsheets? What's the deal with :- operator?
If you do not have aggregates e.g. countofall, negation ~, or recursion in your rules, then a rule of the form NewFact :- Fact1 & Fact2 ... is identical to NewFact is derived If the Conjunction of facts: Fact1, Fact2 ... evaluates to true.
In other cases, extraneous facts may be derived. In order to get rid of these extraneous derivations, the :- operator is introduced. For details, we refer you to an excellent reference on Logic Programming. |