Author proposes a weird primitive: MonotonicList, the almost-immutable list which you can only append to _and you cannot tell the size of_. Author does not mention it, but presumably there should be no other way to tell the size of list as well - for example "out of bounds" error should immediately terminate program instead of emitting catch-able exception.
This means in practice, users have to share (list, size) pairs - and these describe immutable sequences. So... what's the point of forcing user to keep those separately? A structure like "ImmutableListWithFastAppends" (which may be _backed_ by a mutable shared append-only list, but only as an implementation detail) seems much nicer to use - easier to understand, reason about, and is compatible with existing code.
(Author mentions "CALM principle" as a motivation for monotonic collections, but from I can see, they are simply wrong. The original Bloom paper in CIDR'11 is all about monotonic _programs_ - a very restricted programming model. Adding monotonic collections to a regular language like Java or Kotlin brings no benefits, and just makes a convoluted immutable version)
This means in practice, users have to share (list, size) pairs - and these describe immutable sequences. So... what's the point of forcing user to keep those separately? A structure like "ImmutableListWithFastAppends" (which may be _backed_ by a mutable shared append-only list, but only as an implementation detail) seems much nicer to use - easier to understand, reason about, and is compatible with existing code.
(Author mentions "CALM principle" as a motivation for monotonic collections, but from I can see, they are simply wrong. The original Bloom paper in CIDR'11 is all about monotonic _programs_ - a very restricted programming model. Adding monotonic collections to a regular language like Java or Kotlin brings no benefits, and just makes a convoluted immutable version)