A //Containers// is a general name for data structures intended to hold group of elements of certain type.
Considering that almost every program needs containers to store, retrieve, search or otherwise process aggregate data,
obviously efficiency of containers implementation is one of the top priorities for Xreate design.
-Main idea behind containers in Xreate is to gather information on //how containers are used//, inferred from program sources.
-On this ground it's possible to choose semi-automatically most appropriate data structure for container implementation to efficiently fullfil particular needs.
+Main idea behind containers in Xreate is to gather information on //how containers are used//, by inferring from program sources.
+On this ground it's possible to choose semi-automatically the most appropriate data structure for container implementation to efficiently fullfil particular needs.
b= a[0]:: num; op(randaccess). //operation on container
In this example, definition of container(variable `a`) offers one or several implementations it supports, that is `impl(solid)` which
is explicilty provided for clarity. On the other side, //retrieving by index// operation(variable `b`) demands certain implementations
-to operate. Annotation `op(randaccess)` explicitly describes operation nature, i.e. it requires any data structure that supports //random access// .
-Based on gathered information, most appropriate tradeoff //in supply and demand// is applied as given container implementation, i.e. `impl(solid)` in this simple case.
+to operate on. Annotation `op(randaccess)` explicitly describes operation nature, i.e. it requires any data structure that supports //random access// .
+
+Based on gathered information, most appropriate tradeoff //in supply and demand// is assumed as implementation for a given container , i.e. `impl(solid)` in the case above.
+
+Here is a more complex example:
+
+ function test1(i:: num):: num{
+ a = [1..10]:: [num].
+
+ b = loop map(a->el:: num):: [num]{
+ a * a
+ }
+
+ b[i]
+ }
+
+Implementation of `b` assumed to be `impl(soild)` for index operation `b[i]` demands `randaccess` and `impl(solid)` is a most appropriate implementation operator `list` could provide(variable `a`). However, after slight changes as shown below
+
+ function test2:: num {
+ a= [1..10]:: [num].
+
+ b = loop map(a->el:: num):: [num]{
+ a * a
+ }
+
+ c = loop fold(b->el, 0->sum>)::num {
+ sum + el
+ }
+
+ c
+ }
+
+the situation is different. Definitions of `a` as well as `b` are intact, but there is different operaton over `b`, which is iterating to calculate sum of `b` elements. Iteration represented as `op(seqaccess)` depicting //sequental access// to a container data. Different container use leads implementation inference to a different outcomes, `impl(on_the_fly)` in this case.
+
+To conclude, the examples show ability to automatically reassign best suited implementations for a container variables reflecting how exactly variables are processed.
In order to exppress possible and required implementations, describe operations, constraints and preferences an annotations are used, either manually provided or automatically inferred from program sources.