Organize API: Trait names, structure names, programming interface

[matthewhammer]

@kyleheadley Has done a good job writing documentation for his traits and structures. In branch dev-hammer, I've augmented these with a "skiplist" structure and "FinMap" trait, in a somewhat ad hoc manner. I intend to add at least one or two other representations for finite maps / sets. We should start to come up with a system for organizing these sub-modules, and the names of the traits and structure that they contain.

[matthewhammer]

For instance: Many structures contain a common operation archive. Should this be a separate trait with exactly one function? Is this the right name for this function?

[kyleheadley]

I've started to identify uses of Traits that I like and don't like. An "interface" should be determined top-down, and used mainly with trait objects. I'm doing this (essentially) in the eval code, only because I explicitly need to "swap out" one type for another. So I like how the std library doesn't define traits on the use of e.g. vector and linked list. And I don't really see the point of "FinMap".

On the other hand, I think codifying invariants and conventions is a great use of traits. The archive function would be a good one to use in a trait. @matthewhammer and I were discussing how to handle accumulators in higher-order incremental functions. He suggested we have a archive convention for these, and I suggested we explicitly wrap values in ic structs to maintain the convention regardless of the user types. We can have both of these if we require an Archive bound on the accumulator type, and provide a wrapper for non-ic types.

[matthewhammer]

@kyleheadley @jpw234, cc @bechang

We should revisit this issue sometime soon, perhaps as we finalize the formalism of the translation, which targets this API (at least conceptually, and hopefully in a Rust-based implementation of the translation, someday).

In particular:

• Where should traits used throughout the collections modules be defined? (e.g., "finite maps" are defined in a bunch of different places, because Jared and I have not merged our various modules yet).
• What should we call the various collection traits?
• What should we call the various collection types?

Ideally, these choices would be reflected in our on-paper formalism, and we'd use consistent terminology and abstractions in both.