This paper discusses extensions to Bloom to accommodate lattices in multiple domains.
The paper then describes the various details to be accounted for as part of the extension:
how does CALM extend to lattices, how are lattices defined and used in set-oriented logic,
how do built-in lattices work, etc.
In general, I like this work because it provides compelling extensions to a language in
a very concise way. There are certainly directions in performance available, but I also think
the utility of datalog and datalog-like languages are still increasing and expanding to
I feel like this point is not discussed in detail, but the semi-naive evaluation strategy
discussed in 4.1 seems to naturally lend itself to be easy to garbage collect. While I think
it would have been interesting to discuss this point and what pitfalls may exist for more
aggressive garbage collection strategies, I think that this is an indirect benefit of this
evaluation strategy. With regard to the evaluation included in the paper, perhaps even showing
performance of garbage collection strategies would be really nice, since many other distributed
systems papers do not discuss this metric.
I felt that figure 5 and the discussion of performance wasn’t particularly satisfying.
It is already claimed that BloomL is a relatively minor change from Bloom, and the Bloom paper
(Consistency Analysis in Bloom) does not have much runtime evaluation itself. Of course, I
appreciate that some performance metrics were included, but I think it would have been more
interesting to maybe target a specific component or piece of a distributed system to get a more
interesting comparison against an implementation that is not Bloom at all. It would have
even been useful if section 4.2 discussed at a high level what other datalog-like implementations
or distributed systems compute the transitive closure of a graph and have performance metrics,
so that some baseline could be established even if not within the scope of this paper.
I feel that an aspect of evaluation that never seems to come up is something of an HCI
approach: given a task and maybe some example code, ask a developer to implement the
task and see how well it performs. As a follow up evaluation, have that person try to
improve a sub-optimal implementation. Since this work on CALM and bloom takes a different
approach to addressing monotonicity compared to CRDTs, and because the whole point of CRDTs
and CALM is to make writing distributed programs easier (I think), it seems like usability
or programmability should be an important aspect of evaluation.
I wonder if adding fixpoint semantics to other languages would be all that is needed to make
them more concise for the use cases described in this paper.