Lihata design decisions
0. Goals
Lihata should (in order of importance):
- [R1] be able to represent sorted lists
- [R2] be able to represent hashes (key-value pairs, with optionally unique keys)
- [R3] be able to represent tables
- [R4] allow embed any object into any other, forming trees
- [R5] do all this with minimal syntax overhead (i.e. no need to use "" around strings unless they contain characters that should be protected)
- [R6] prefer simple/common cases in the syntax (i.e. common cases should require less typing, exotic/rare cases more typing)
- [R7] have a the based on short keywords instead of depending on different behavior of different braces
- [R8] support streams/sessions/transactions and data marshaling
- [R9] besides being convenient for the experienced user, it should be easily understood to a shallow level for the user novice to lihata: such users shall be able to edit lihata files for small modifications without having to refer to the manual for the most common cases (i.e. copying patterns seen in the file).
- [R10] the maze of possibilities offered by the syntax should always have a fallback: a more verbose solution that just works