It's a good-ish summary and your range `[3..5]` is another great example why we
might want two operators since one could also do a range of `{"RFCs" ..
"the"}`. The augmented tree actually keeps things like "the number of nodes
below a node" (or "to the left") and can do a height-of-tree time search to
find a node of a given rank. You don't really need much more than a `SortedSeq`
to really demonstrate the interface issue, as mentioned in the long discussion,
though. (If you want a simpler algorithmic mental model.)
Some clarifications. We don't ever need to break how `Table` is accessed (or
`seq`). We could only do the `[]` and `{}` for the new bag/sorted bag thing
(which is not yet impled in Nim (I have C impls to port)). I think the
extent/impact of this idea was misunderstood because there is so little
exposure to unkeyed "search" trees. (I've seen some AVL "rope" libraries, the
Python blist, etc., but it's definitely off the beaten path). A lot of words
were spilled with me trying to explain that.
Mostly, what I think I am getting pushback on (it's not exactly clear) is
providing `{}/{}=` for `Table` merely as an "alias" after these impls are all
in play. That way `{}` could mean "associative-ish" while `[]` could mean
`positional-ish` as a more global convention like the `add` vs `append` proc or
other things in `doc/apis.rst`. We could preserve backward compatibility
forever. Right now `{}=` is only used in the `json` module. The `{}` for
`Table` is just to make it easier to have the object be either a tree or a
table. `CritBitTree` and maybe something else might also benefit from that kind
of operator alias (and might be algorithmically updatable to an instrumented
tree, actually...Haven't thought about that).
It's possible push back is more general, like "don't ever use two indexing
operators like `[]/{}` for some core thing like a tree/sortedseq!" or "don't
ever add an alias for `Table.[]!!`". I don't mean to speak for anyone.
It's not like this is a huge deal to me (however much I may write). It's a
neglected interface detail because few libraries have multiassociative things
until late in the syntax game, but we soon will, and Nim's fabulously flexible
syntax already supports it. It's more consistent with initializer syntax like
`{:}` and highlights possibly slow associative lookup. I feel like if you like
`{key:val, ..}` at all more than `@[(key,val),..` then this kind of move would
be welcome.
Tutorials/intros/explainers of the language do have to decide "Do I favor
internal consistency/clarity of mentioning `{}` early or do I favor similarity
to other prog.langs". I think that about covers the real questions. Oh, and the
alternatives to these are to always use `[]` but with type constructors inside
to distinguish the "access mode".
