
Monotonicity Types: Towards a Type System for Eventual Consistency - cmeiklejohn
http://prl.ccs.neu.edu/blog/2017/10/22/monotonicity-types-towards-a-type-system-for-eventual-consistency/
======
warent
For anybody looking for additional footing on understanding this, I found the
following to be very helpful: [http://bloom-lang.net/calm/](http://bloom-
lang.net/calm/)

Personally, I've never done programming on distributed systems before so
please correct me if I'm off at any point. The issue seems quite clear: you
want to ensure that your function mutates inputs (or returns values relative
to inputs) in a predictable way with values headed in one direction--
increasing or decreasing. So, the idea of monotonicity types actually seems
quite intuitive: ensure your outputs monotonicity are well-defined. It's
mildly surprising this isn't something that has already been implemented.

On the other hand, could this monotonic type could be more generalized? Maybe
something less two-dimensional, though perhaps this is overkill for most uses.

Also, as an aside, I don't have a Ph.D. in comp. sci, type theory,
mathematics, or anything for that matter. This article was borderline
gobbledygook to me and could be summarized far more succinctly (in a manner
more friendly to the general programming public?)

------
fmap
Great work and obscure enough that I'm sure one of the authors made the
submission :)

If so, here are a few things that I saw while glancing over the paper (I'll
read the paper in detail later):

\- you might be interested in neel krishnaswami's paper on datafun, which is a
functional language that includes datalog primitives in the form of least
fixed points of monotone functions. Monotonicity is tracked in the type
system, so this seems very relevant.

Edit: just saw that the paper was referenced after all, my bad!

\- why do you need termination? Is it an artifact of the logical relation you
use? If so, step indexing might help to relax this restriction.

~~~
rntz
I'm actually the Datafun paper's other author, so folks can AMA if they're
interested in Datafun.

It's very interesting to me to see the connections and differences here:

\- Monotonicity Types and Datafun both track monotonicity, but for entirely
different purposes; MT for CRDTs & distributed programming, Datafun for
enforcing termination on recursive queries.

\- MT uses a refinement-type-style system, while Datafun uses a modal type
system. It's not clear to me whether this is related to their different use-
cases, or just an accident of history.

\- Relatedly, MT builds on an existing language (Lasp, which itself builds on
Erlang), while Datafun is entirely new. MT is definitely more practical in
this respect. My hope is that Datafun, while not practical to use directly
yet, will have a big impact in the long run, as its namesake Datalog did, but
that's just a dream :).

\- MT and Datafun both care about semilattices: MT because CRDTs are based on
semilattices, and Datafun because they give a natural and general way to
comprehend over sets, and also guarantee a "bottom element" for our fixed-
points to start computing from.

\- Datafun has two kinds of function: monotone (preserves ordering) and
discrete (could do anything). MT has _five_ qualifiers on function arguments,
representing whether the function respects the ordering, inverts the ordering,
disrespects the ordering, ignores the argument entirely, or returns that
argument unchanged. Wow! Are all those qualifiers really necessary? Maybe.
Antitone functions (order-inverting) are something we're considering adding to
Datafun, at least.

------
doomrobo
Could anyone provide some intuition for what's supposed to be happening in the
sample code?

~~~
yorwba
The first few lines define the interface that is going to be used and its
monotonicity properties. E.g. _getAt :: (m : NatMap, k : Nat) ⇒ Nat[↑ m, ? k]_
means that when you get the value of key _k_ in the map _m_ , the result is a
number that increases as the map increases.

Based on the names, I guess that _getAt_ is for value access, _joinAt_ updates
an entry of a map with a new value, _span_ returns the maximum key with an
associated entry, _max_ is the maximum of two numbers, _emptyMap_ is a map
without entries and + and > are the usual mathematical functions. The
_GCounter_ type is essentially just a wrapper around maps that will be used to
count things, apparently.

The function _sumCounters_ they define first unwraps the maps backing the
counters and determines the maximum key that will have to be considered.

Then there's a helper function _sumCell_ which takes a key _k_ and an
accumulator _acc_ containing the intermediate result for all previous keys.
The helper function then checks whether all keys have been handled already,
and returns the accumulator if that's the case. Otherwise it updates the
accumulator with the sum of the entries for the given key in the two input
maps. Then it calls itself recursively to handle the next key with the new
accumulator.

The final line just starts off the helper function with an empty accumulator
and the first key.

------
auggierose
Great. 35 points and no discussion. I’d say that tells you SOMETHING about
type theory.

~~~
nine_k
E.g. it says: we need time to actually read the paper.

~~~
auggierose
Funny. If only.

