cleaned up the tests; fixes #30; fixes #26

doc/manual.txt

@@ -346,10 +346,10 @@ notation:
 ``0B0_10001110100_0000101001000111101011101111111011000101001101001001'f64``
 is approximately 1.72826e35 according to the IEEE floating point standard.
 
-
-Operators
----------
-
+
+Operators
+---------
+
 In Nimrod one can define his own operators. An `operator`:idx: is any
 combination of the following characters::
 
@@ -358,14 +358,14 @@ combination of the following characters::
        !     ?     ^     .     :     \
 
 These keywords are also operators:
-``and or not xor shl shr div mod in notin is isnot``.
-
-`=`:tok:, `:`:tok:, `::`:tok: are not available as general operators; they
-are used for other notational purposes. 
-
-``*:`` is as a special case the two tokens `*`:tok: and `:`:tok:
+``and or not xor shl shr div mod in notin is isnot``.
+
+`=`:tok:, `:`:tok:, `::`:tok: are not available as general operators; they
+are used for other notational purposes. 
+
+``*:`` is as a special case the two tokens `*`:tok: and `:`:tok:
 (to support ``var v*: T``).
-
+
 
 Other tokens
 ------------
@@ -373,10 +373,10 @@ Other tokens
 The following strings denote other tokens::
 
     `   (     )     {     }     [     ]     ,  ;   [.    .]  {.   .}  (.  .)
-
-
-The `slice`:idx: operator `..`:tok: takes precedence over other tokens that 
-contain a dot: `{..}`:tok: are the three tokens `{`:tok:, `..`:tok:, `}`:tok: 
+
+
+The `slice`:idx: operator `..`:tok: takes precedence over other tokens that 
+contain a dot: `{..}`:tok: are the three tokens `{`:tok:, `..`:tok:, `}`:tok: 
 and not the two tokens `{.`:tok:, `.}`:tok:.
 
 
@@ -398,7 +398,7 @@ Precedence level    Operators                                     First characte
   9 (highest)                                                     ``$  ^``            OP9
   8               ``*    /    div   mod   shl  shr  %``           ``* % \  /``        OP8
   7               ``+    -``                                      ``+  ~  |``         OP7
-  6               ``&``                                           ``&``               OP6
+  6               ``&``                                           ``&``               OP6
   5               ``..``                                          ``.``               OP5
   4               ``==  <= < >= > !=  in not_in is isnot not``    ``= <  > !``        OP4
   3               ``and``                                                             OP3
@@ -1815,34 +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
+
+
+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 
+
+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.
+
+* 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
@@ -2248,7 +2248,7 @@ introduce type parameters or to instantiate a generic proc, iterator or type.
 
 
 Templates
-~~~~~~~~~
+---------
 
 A `template`:idx: is a simple form of a macro: It is a simple substitution
 mechanism that operates on Nimrod's abstract syntax trees. It is processed in
@@ -2372,6 +2372,24 @@ powerful programming construct that still suffices. So the "check list" is:
 (3) Else: Use a template, if possible.
 (4) Else: Use a macro.
 
+Identifier construction
+~~~~~~~~~~~~~~~~~~~~~~~
+
+In templates identifiers can be constructed with the backticks notation:
+
+.. code-block:: nimrod
+
+  template typedef(name: expr, typ: typeDesc) = 
+    type
+      `T name`* = typ
+      `P name`* = ref `T name`
+      
+  typedef(myint, int)
+  var x: PMyInt
+
+In the example ``name`` is instantiated with ``myint``, so \`T name\` becomes
+``Tmyint``.
+
 
 Macros
 ------
@@ -2986,10 +3004,10 @@ string expressions in general:
   proc myImport(s: cstring) {.cdecl, importc, dynlib: getDllName().}
 
 **Note**: Patterns like ``libtcl(|8.5|8.4).so`` are only supported in constant
-strings, because they are precompiled.
-
-**Note**: Passing variables to the ``dynlib`` pragma will fail at runtime 
-because of order of initialization problems.
+strings, because they are precompiled.
+
+**Note**: Passing variables to the ``dynlib`` pragma will fail at runtime 
+because of order of initialization problems.
 
 
 Dynlib pragma for export