Revised design for table type

[jclark]

There's a discussion here:

https://groups.google.com/forum/#!msg/ballerina-dev/b4GM_sGXA64/GJV75EaCGQAJ

[jclark]

A few more issues:

• Restriction on primary keys being simple could potentially be lifted by using frozen values or cloning
• Frank commented on the Google Docs about the significance of column order. I checked the SQL spec and he was right. Columns in SQL are ordered.
• We should consider spreadsheets use case (Pyret emphasizes this).
• How do we write the type that contains all values of basic type table?
• Should we add back table<T> syntax? One reason for getting rid of it was open/closed record issue.
• Maybe also consider NoSQL use case (perhaps open records make more sense here).
• Need to define some built-in methods.

[jclark]

We will also need to

• add a lang.table module
• define how value:toString works for table values

[jclark]

See issue #286 for a proposal that covers these.

[jclark]

It is clear that the approach of the proposal in #286 is not the right approach. We need an approach that does not clone tables. This will need a fresh proposal.

In the meantime, we have a query feature that is not table specific (see #398, #340), and we have streams #406, which cover the iterator-type usage of tables in the existing implementation.

We are no longer trying to make a table be a transparent proxy for an SQL table. This is inconsistent with Ballerina's approach to network error handling.

[jclark]

There is now a new proposal.

[jclark]

We can split the changes into the following:

• Add new table type descriptor [done]
• Add new table constructor [done]
• Add new table langlib module [done]
• Type of anydata changes to allow table<map<anydata>> not arbitrary table [done]
• Allow query-expr to start with a table and a key-specifier [done]
• Define value:toString for tables [done]
• Make member access expressions work for table [done]
• Make t[x,y] be sugar for t[[x,y]] [done]
• Fix introductory text at beginning of structures section [done]

[jclark]

User control over duplicate keys in a query-expr that creates a table is a separate issue #481.

[jclark]

Made the iterator problem be a separate issue #485.