![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
---
i want the programmer to be able to alter data by making an declarative assertion using ontologies/logic, and then to have that be mappped to eg an entry in a database, or a change in some OOP data structures. This might require some work by the programmer to map the ontology onto the data structure they are using. But the benefit is making the program more readable, and also in decoupling the information itself from the shape of its storage data structures. Of course, the synttax for these logic statements must be no less concise than making the data structure change directly
---
natural language constants for kythe things like alias and defines and annotates-with-metadata, but also ootcore things like forall, conditional. note that some oot core things seem to do double duty as imperative control and logical assertions, eg forall/foreach, if. is Kythe annotateswithmetadata different from transactions b/c that is content, not meta? i think so. distinguishing 'content' and 'meta' annotations is another poteetial way of having 'levels'.
---
first-class declarative "facts" (and hypotheticals) can be first-class assignments: examples:
but then shouldnt assignments look like edges (eg, use the '/' symbol, like edges in graph constructors, instead of the '=' symbol that we are so far planning to use in ordinary assignments)? or, mb ordinary assignments are facts which are immediately executed. or mb assignments return facts, and if a fact is returned at the top level of an expression (except for the expression at the end of its block), it is executed
or, should a block return ALL facts generated in the block (eg should {a = 3; b = 4;} return a list of two facts? now a block is looking like a monad.. but less metaprogrammable (which i think is good) (the reason it is less metaprogrammable is that, in a monad, in between each 'statement' the monad gets to do arbitrary things).
'!' could be used to execute the facts returned by an expression (eg to propagate assignments to some durable datastore)
todo should lookup how clojure does stm, and how datomic doees facts, for our firstclass facts
on datomic:
" Immutable Data
Datomic is built upon the model of data consisting of immutable values. How can data be immutable? Don't facts change? They don't, in fact, when you incorporate time in the data. For instance, when Obama became president, it didn't mean that Bush was never president. As long as who is president isn't stored in a single (logical) place, there's no reason a database system couldn't retain both facts simultaneously. While many queries might be interested in the 'current' facts, others might be interested in, e.g. what the product catalog looked like last month compared to this month. Incorporating time in data allows the past to be retained (or not), and supports point-in-time queries. Many real world systems have to retain all changes, and struggle mightily to efficiently provide the 'latest' view in a traditional database. This all happens automatically in Datomic. Datomic is a database of facts, not places.
Atomic Data - the Datom
Once you are storing facts, it becomes imperative to choose an appropriate granularity for facts. If you want to record the fact that Sally likes pizza, how best to do so? Most databases require you to update either the Sally record or document, or the set of foods liked by Sally, or the set of likers of pizza. These kind of representational issues complicate and rigidify applications using relational and document models. This can be avoided by recording facts as independent atoms of information. Datomic calls such atomic facts 'datoms'. A datom consists of an entity, attribute, value and transaction (time). In this way, any of those sets can be discovered via query, without embedding them into a structural storage model that must be known by applications. "
ok, so this is like us, except they are wedding to RDF triples + time, and we allow other modes in addition (and are we even in love with RDF triples?)
---
need ('modals') for annotations: 'requires' vs 'prefers'. (generalize this to 'strict' vs. 'approx'? no, b/c we might require a requirement which is approximate, eg probably approximately correct)
