slice support in system.nim; syntactic sugar for tables; cleanup of grammar/parser

doc/grammar.txt

@@ -21,12 +21,11 @@ plusExpr ::= mulExpr (OP7 optInd mulExpr)*
 mulExpr ::= dollarExpr (OP8 optInd dollarExpr)*
 dollarExpr ::= primary (OP9 optInd primary)*
 
-indexExpr ::= expr ['=' expr]
+indexExpr ::= expr
 
 castExpr ::= 'cast' '[' optInd typeDesc optPar ']' '(' optInd expr optPar ')'
 addrExpr ::= 'addr' '(' optInd expr optPar ')'
-symbol ::= '`' (KEYWORD | IDENT | operator | '(' ')'
-               | '[' (',' | ['$'] '..' ['$'])* ']'
+symbol ::= '`' (KEYWORD | IDENT | operator | '(' ')' | '[' ']'
                | '=' | literal)+ '`'
          | IDENT
          

doc/manual.txt

@@ -1815,6 +1815,34 @@ Example:
 An if expression always results in a value, so the ``else`` part is
 required. ``Elif`` parts are also allowed (but unlikely to be good
 style).
+
+
+Table constructor
+~~~~~~~~~~~~~~~~~
+
+A `table constructor`:idx: is syntactic sugar for an array constructor:
+
+.. code-block:: nimrod
+  {"key1": "value1", "key2": "value2"}
+  
+  # is the same as:
+  [("key1", "value1"), ("key2", "value2")]
+
+
+The empty table can be written ``{:}`` (in contrast to the empty set 
+which is ``{}``) which is thus another way to write as the empty array
+constructor ``[]``. This slightly unusal way of supporting tables 
+has lots of advantages:
+
+* The order of the (key,value)-pairs is preserved, thus it is easy to
+  support ordered dicts with for example ``{key: val}.newOrderedTable``.
+* A table literal can be put into a ``const`` section and the compiler
+  can easily put it into the executable's data section just like it can
+  for arrays and the generated data section requires a minimal amount
+  of memory.
+* Every table implementation is treated equal syntactically.
+* Apart from the minimal syntactic sugar the language core does not need to
+  know about tables.
 
 
 Type conversions