@@ -19,14 +19,14 @@ The central software component of functional-relational programming is a relatio
1919"Out of the Tarpit" recommends the relational model not only in its customary backend role, but throughout the application because the relational model is:
2020
2121* **declarative**: thus removing accidental complexity (such as accidental ordering)
22−* **restricted**: the paper makes it clear that if a programming language allows a programmer to do something less-than-savory, then that misfeature will be used
22+* **restricted**: removing mistaken features; if a programming language allows a programmer to do something less-than-savory, then that misfeature will be used
2323
2424and provides ([p.37](http://shaffner.us/cs/papers/tarpit.pdf)):
2525
2626* **structure**: a closed world system whereby all data is represented by relations
2727* **manipulation**: a means to simulate mutation of the application state over time
2828* **data integrity**: constraints which prevent illogical data constructions
29−* **data independence**: the logical and physical representations of state are clearly separated
29+* **data independence**: logical and physical representations of state which are clearly separated
3030
3131The relational model is a mathematical model for storing and manipulating "essential state" ([p.25](http://shaffner.us/cs/papers/tarpit.pdf)). As a mathematical model, it not beholden to any specific implementation or quirks.
3232
@@ -55,7 +55,29 @@ Project:M36 implements multiple interfaces:
5555
5656### Real Estate Database Example
5757
58−To understand how Project:M36 stacks up against the fictional programming language shown in the paper, we have implemented the [example from the paper](/examples/out_of_the_tarpit.tutd). The language used in the script is a dialect of Chris Date's TutorialD language.
58+To understand how Project:M36 stacks up against the fictional programming language shown in the paper, we have implemented the [example from the paper](/examples/out_of_the_tarpit.tutd). The language used in the script is a dialect of Chris Date's TutorialD language. It can be loaded into an interactive ```tutd``` session like so:
59+
60+```
61+TutorialD (master): :importtutd "examples/out_of_the_tarpit.tutd"
62+TutorialD (master): :showexpr property
63+┌───────────────────┬────────────┬───────────────────┬────────────┬────────────┐
64+│address::Address │agent::Agent│dateRegistered::Day│photo::Text │price::Price│
65+├───────────────────┼────────────┼───────────────────┼────────────┼────────────┤
66+│Address "Main St." │Agent "Bob" │Day 2014-01-01 │"photo1.jpg"│Price 1000.0│
67+│Address "Elm St." │Agent "Bob" │Day 2014-01-03 │"photo2.jpg"│Price 1200.0│
68+│Address "Maple St."│Agent "Sam" │Day 2014-02-05 │"photo3.jpg"│Price 800.0 │
69+└───────────────────┴────────────┴───────────────────┴────────────┴────────────┘
70+```
71+
72+Project:M36 meets or exceeds the enumerated "Infrastructure" ([p.47](http://shaffner.us/cs/papers/tarpit.pdf)) requirements (except one):
73+
74+* **Infrastructure for Essential State**: relation variable manipulation, storage, and data types
75+* **Infrastructure for Essential Logic**: relational expression evaluation, functions to operate on values, a language (TutorialD or Haskell), type inference, and constraints
76+* **Infrastructure for Accidental State and Control**: data independence (how relations are defined need not reflect how they are stored or manipulated)
77+* **Infrastructure for Feeders and Observers**: insert/update/delete and change notifications (including historical state retrieval)
78+
79+
80+Derived relations, as described in the paper, are not supported in Project:M36 because it is not clear that they are mathematically coherent. Regardless, it is clear that, while handy, derived relations (also known in SQL as "views") are not a requirement of the relational algebra.
5981
6082### Feeders and Observers
6183
@@ -74,11 +96,24 @@ Project:M36 is a clean-room implementation of a relational algebra engine; it do
7496* [three-valued logic (NULL)](/docs/on_null.markdown)
7597* non-relational database constructs such as row and column ordering or OUTER JOINs
7698* linear transaction flow and conflict resolution
77−* direct table-to-file mapping which create perverse model-data dependencies
99+* direct table-to-file mappings which create perverse model-data dependencies
78100* key-value storage: a key-value mapping is valued merely for its performance characteristics, not because it models reality well
79101* restrictive, legacy type systems which impede modeling
80102* unnecessarily complex SQL grammar
81103
104+## Summary of Benefits of This architecture
105+
106+The "Out of the Tarpit" summarizes the benefits of functional relational programming, but here is a summary of the summary:
107+
108+### Benefits For State
109+
110+* useless accidental state is avoided
111+* constraints prevent entering any "bad" or unexpected state
112+* referential transparency (functional purity)
113+* declarative programming opens greater doors for optimizations
114+
115+### Benefits For control
116+
82117## Future Directions
83118
84119Project:M36 is just getting started as an ambitious open-source project- please join us! Immediate future features include: