the big renamefest: first steps

4 files changed, 246 insertions, 249 deletions

diff --git a/doc/exception_hierarchy_fragment.txt b/doc/exception_hierarchy_fragment.txt
index 6ca68921f..f4a419fc4 100644
--- a/doc/exception_hierarchy_fragment.txt
+++ b/doc/exception_hierarchy_fragment.txt
@@ -1,31 +1,28 @@
-* `E_Base <system.html#E_Base>`_
-  * `EAccessViolation <system.html#EAccessViolation>`_
-  * `EArithmetic <system.html#EArithmetic>`_
-    * `EDivByZero <system.html#EDivByZero>`_
-    * `EOverflow <system.html#EOverflow>`_
-  * `EAssertionFailed <system.html#EAssertionFailed>`_
-  * `EAsynch <system.html#EAsynch>`_
-    * `EControlC <system.html#EControlC>`_
-  * `EDeadThread <system.html#EDeadThread>`_
-  * `EFloatingPoint <system.html#EFloatingPoint>`_
-    * `EFloatDivByZero <system.html#EFloatDivByZero>`_
-    * `EFloatInexact <system.html#EFloatInexact>`_
-    * `EFloatInvalidOp <system.html#EFloatInvalidOp>`_
-    * `EFloatOverflow <system.html#EFloatOverflow>`_
-    * `EFloatUnderflow <system.html#EFloatUnderflow>`_
-  * `EInvalidField <system.html#EInvalidField>`_
-  * `EInvalidIndex <system.html#EInvalidIndex>`_
-  * `EInvalidObjectAssignment <system.html#EInvalidObjectAssignment>`_
-  * `EInvalidObjectConversion <system.html#EInvalidObjectConversion>`_
-  * `EInvalidValue <system.html#EInvalidValue>`_
-    * `EInvalidKey <system.html#EInvalidKey>`_
-  * `ENoExceptionToReraise <system.html#ENoExceptionToReraise>`_
-  * `EOutOfRange <system.html#EOutOfRange>`_
-  * `ESynch <system.html#ESynch>`_
-    * `EOutOfMemory <system.html#EOutOfMemory>`_
-    * `EResourceExhausted <system.html#EResourceExhausted>`_
-    * `EStackOverflow <system.html#EStackOverflow>`_
-    * `ESystem <system.html#ESystem>`_
-      * `EIO <system.html#EIO>`_
-      * `EOS <system.html#EOS>`_
-        * `EInvalidLibrary <system.html#EInvalidLibrary>`_
+* `Exception <system.html#Exception>`_
+  * `AccessViolationError <system.html#AccessViolationError>`_
+  * `ArithmeticError <system.html#ArithmeticError>`_
+    * `DivByZeroError <system.html#DivByZeroError>`_
+    * `OverflowError <system.html#OverflowError>`_
+  * `AssertionError <system.html#AssertionError>`_
+  * `DeadThreadError <system.html#DeadThreadError>`_
+  * `FloatingPointError <system.html#FloatingPointError>`_
+    * `FloatDivByZeroError <system.html#FloatDivByZeroError>`_
+    * `FloatInexactError <system.html#FloatInexactError>`_
+    * `FloatInvalidOpError <system.html#FloatInvalidOpError>`_
+    * `FloatOverflowError <system.html#FloatOverflowError>`_
+    * `FloatUnderflowError <system.html#FloatUnderflowError>`_
+  * `FieldError <system.html#InvalidFieldError>`_
+  * `IndexError <system.html#InvalidIndexError>`_
+  * `ObjectAssignmentError <system.html#ObjectAssignmentError>`_
+  * `ObjectConversionError <system.html#ObjectConversionError>`_
+  * `ValueError <system.html#ValueError>`_
+    * `KeyError <system.html#KeyError>`_
+  * `ReraiseError <system.html#ReraiseError>`_
+  * `RangeError <system.html#RangeError>`_
+  * `OutOfMemoryError <system.html#OutOfMemoryError>`_
+  * `ResourceExhaustedError <system.html#ResourceExhaustedError>`_
+  * `StackOverflowError <system.html#StackOverflowError>`_
+  * `SystemError <system.html#SystemError>`_
+    * `IOError <system.html#IOError>`_
+    * `OSError <system.html#OSError>`_
+      * `LibraryError <system.html#LibraryError>`_
diff --git a/doc/lib.txt b/doc/lib.txt
index 26ea1b735..a29e32429 100644
--- a/doc/lib.txt
+++ b/doc/lib.txt
@@ -1,15 +1,15 @@
-=======================
-Nimrod Standard Library
-=======================
+====================
+Nim Standard Library
+====================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
   "The good thing about reinventing the wheel is that you can get a round one."
 
-Though the Nimrod Standard Library is still evolving, it is already quite
+Though the Nim Standard Library is still evolving, it is already quite
 usable. It is divided into *pure libraries*, *impure libraries* and *wrappers*.
 
 Pure libraries do not depend on any external ``*.dll`` or ``lib*.so`` binary
@@ -19,7 +19,7 @@ low-level interface to a C library.
 Read this `document <apis.html>`_ for a quick overview of the API design.
 
 The `bottom <#babel>`_ of this page includes a list of 3rd party packages
-created by the Nimrod community. These packages are a useful addition to the
+created by the Nim community. These packages are a useful addition to the
 modules in the standard library.
 
 
@@ -41,27 +41,27 @@ Core
   of ``system``, but an extra import.
 
 * `threads <threads.html>`_
-  Nimrod thread support. **Note**: This is part of the system module. Do not
+  Nim thread support. **Note**: This is part of the system module. Do not
   import it explicitly.
 
 * `channels <channels.html>`_
-  Nimrod message passing support for threads. **Note**: This is part of the 
+  Nim message passing support for threads. **Note**: This is part of the 
   system module. Do not import it explicitly.
 
 * `locks <locks.html>`_
-  Locks and condition variables for Nimrod.
+  Locks and condition variables for Nim.
 
 * `macros <macros.html>`_
-  Contains the AST API and documentation of Nimrod for writing macros.
+  Contains the AST API and documentation of Nim for writing macros.
 
 * `typeinfo <typeinfo.html>`_
-  Provides (unsafe) access to Nimrod's run time type information. 
+  Provides (unsafe) access to Nim's run time type information. 
 
 * `typetraits <typetraits.html>`_
   This module defines compile-time reflection procs for working with types.
 
 * `actors <actors.html>`_
-  Actor support for Nimrod; implemented as a layer on top of the threads and
+  Actor support for Nim; implemented as a layer on top of the threads and
   channels modules.
 
 
@@ -71,11 +71,11 @@ Collections and algorithms
 * `algorithm <algorithm.html>`_
   Implements some common generic algorithms like sort or binary search.
 * `tables <tables.html>`_
-  Nimrod hash table support. Contains tables, ordered tables and count tables.
+  Nim hash table support. Contains tables, ordered tables and count tables.
 * `sets <sets.html>`_
-  Nimrod hash and bit set support.
+  Nim hash and bit set support.
 * `lists <lists.html>`_
-  Nimrod linked list support. Contains singly and doubly linked lists and
+  Nim linked list support. Contains singly and doubly linked lists and
   circular lists ("rings").
 * `queues <queues.html>`_
   Implementation of a queue. The underlying implementation uses a ``seq``.
@@ -153,11 +153,11 @@ Generic Operating System Services
 * `streams <streams.html>`_
   This module provides a stream interface and two implementations thereof:
   the `PFileStream` and the `PStringStream` which implement the stream
-  interface for Nimrod file objects (`TFile`) and strings. Other modules
+  interface for Nim file objects (`TFile`) and strings. Other modules
   may provide other implementations for this standard stream interface.
 
 * `marshal <marshal.html>`_
-  Contains procs for serialization and deseralization of arbitrary Nimrod 
+  Contains procs for serialization and deseralization of arbitrary Nim 
   data structures.
 
 * `terminal <terminal.html>`_
@@ -273,7 +273,7 @@ Parsers
   parser. The configuration file's syntax is similar to the Windows ``.ini``
   format, but much more powerful, as it is not a line based parser. String
   literals, raw string literals and triple quote string literals are supported
-  as in the Nimrod programming language.
+  as in the Nim programming language.
 
 * `parsexml <parsexml.html>`_
   The ``parsexml`` module implements a simple high performance XML/HTML parser.
@@ -340,7 +340,7 @@ Cryptography and Hashing
 
 * `hashes <hashes.html>`_
   This module implements efficient computations of hash values for diverse
-  Nimrod types.
+  Nim types.
 
 * `md5 <md5.html>`_
   This module implements the MD5 checksum algorithm.
@@ -353,7 +353,7 @@ Multimedia support
 ------------------
 
 * `colors <colors.html>`_
-  This module implements color handling for Nimrod. It is used by
+  This module implements color handling for Nim. It is used by
   the ``graphics`` module.
 
 
@@ -426,12 +426,12 @@ Other
 -----
 
 * `graphics <graphics.html>`_
-  This module implements graphical output for Nimrod; the current
+  This module implements graphical output for Nim; the current
   implementation uses SDL but the interface is meant to support multiple
   backends some day.
 
 * `dialogs <dialogs.html>`_
-  This module implements portable dialogs for Nimrod; the implementation
+  This module implements portable dialogs for Nim; the implementation
   builds on the GTK interface. On Windows, native dialogs are shown if
   appropriate.
 
@@ -444,7 +444,7 @@ Other
 
 * `ssl <ssl.html>`_
   This module provides an easy to use sockets-style 
-  Nimrod interface to the OpenSSL library.
+  Nim interface to the OpenSSL library.
 
 * `rdstdin <rdstdin.html>`_
   This module contains code for reading from `stdin`:idx:. On UNIX the GNU
@@ -532,7 +532,7 @@ Database support
 * `odbcsql <odbcsql.html>`_
   interface to the ODBC driver.
 * `sphinx <sphinx.html>`_
-  Nimrod wrapper for ``sphinx``.
+  Nim wrapper for ``sphinx``.
 
 
 XML Processing
@@ -578,15 +578,15 @@ Scientific computing
 Babel
 ====================
 
-Babel is a package manager for the Nimrod programming language.
+Babel is a package manager for the Nim programming language.
 For instructions on how to install Babel packages see
-`its README <https://github.com/nimrod-code/babel#readme>`_.
+`its README <https://github.com/nim-code/babel#readme>`_.
 
 Official packages
 -----------------
 
 These packages are officially supported and will therefore be continually
-maintained to ensure that they work with the latest versions of the Nimrod
+maintained to ensure that they work with the latest versions of the Nim
 compiler.
 
 .. raw:: html
@@ -597,9 +597,9 @@ compiler.
 Unofficial packages
 -------------------
 
-These packages have been developed by independent Nimrod developers and as
+These packages have been developed by independent Nim developers and as
 such may not always be up to date with the latest developments in the
-Nimrod programming language.
+Nim programming language.
 
 .. raw:: html
 
@@ -607,4 +607,4 @@ Nimrod programming language.
   babelpkglist.js or have javascript disabled in your browser.</b></div>
 
   <script type="text/javascript" src="babelpkglist.js"></script>
-  <script type="text/javascript" src="http://build.nimrod-lang.org/packages?callback=gotPackageList"></script>
+  <script type="text/javascript" src="http://build.nim-lang.org/packages?callback=gotPackageList"></script>
diff --git a/doc/manual.txt b/doc/manual.txt
index 89a417fb2..d18ede409 100644
--- a/doc/manual.txt
+++ b/doc/manual.txt
@@ -1,9 +1,9 @@
-=============
-Nimrod Manual
-=============
+==========
+Nim Manual
+==========
 
 :Authors: Andreas Rumpf, Zahary Karadjov
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
@@ -17,11 +17,11 @@ Nimrod Manual
 About this document
 ===================
 
-**Note**: This document is a draft! Several of Nimrod's features need more
+**Note**: This document is a draft! Several of Nim's features need more
 precise wording. This manual will evolve into a proper specification some
 day.
 
-This document describes the lexis, the syntax, and the semantics of Nimrod.
+This document describes the lexis, the syntax, and the semantics of Nim.
 
 The language constructs are explained using an extended BNF, in
 which ``(a)*`` means 0 or more ``a``'s, ``a+`` means 1 or more ``a``'s, and
@@ -48,14 +48,14 @@ and ``a ^* b`` is short for ``(a (b a)*)?``. Example::
 
   arrayConstructor = '[' expr ^* ',' ']'
 
-Other parts of Nimrod - like scoping rules or runtime semantics are only
+Other parts of Nim - like scoping rules or runtime semantics are only
 described in an informal manner for now.
 
 
 Definitions
 ===========
 
-A Nimrod program specifies a computation that acts on a memory consisting of
+A Nim program specifies a computation that acts on a memory consisting of
 components called `locations`:idx:. A variable is basically a name for a
 location. Each variable and location is of a certain `type`:idx:. The
 variable's type is called `static type`:idx:, the location's type is called
@@ -107,7 +107,7 @@ Lexical Analysis
 Encoding
 --------
 
-All Nimrod source files are in the UTF-8 encoding (or its ASCII subset). Other
+All Nim source files are in the UTF-8 encoding (or its ASCII subset). Other
 encodings are not supported. Any of the standard platform line termination
 sequences can be used - the Unix form using ASCII LF (linefeed), the Windows
 form using the ASCII sequence CR LF (return followed by linefeed), or the old
@@ -118,13 +118,13 @@ used equally, regardless of platform.
 Indentation
 -----------
 
-Nimrod's standard grammar describes an `indentation sensitive`:idx: language.
+Nim's standard grammar describes an `indentation sensitive`:idx: language.
 This means that all the control structures are recognized by indentation.
 Indentation consists only of spaces; tabulators are not allowed.
 
 The indentation handling is implemented as follows: The lexer annotates the
 following token with the preceding number of spaces; indentation is not
-a separate token. This trick allows parsing of Nimrod with only 1 token of
+a separate token. This trick allows parsing of Nim with only 1 token of
 lookahead.
 
 The parser uses a stack of indentation levels: the stack consists of integers
@@ -188,7 +188,7 @@ which code snippet the comment refers to.
 Identifiers & Keywords
 ----------------------
 
-Identifiers in Nimrod can be any string of letters, digits
+Identifiers in Nim can be any string of letters, digits
 and underscores, beginning with a letter. Two immediate following
 underscores ``__`` are not allowed::
 
@@ -209,12 +209,12 @@ The following keywords are reserved and cannot be used as identifiers:
 Some keywords are unused; they are reserved for future developments of the
 language.
 
-Nimrod is a `style-insensitive`:idx: language. This means that it is not
+Nim is a `style-insensitive`:idx: language. This means that it is not
 case-sensitive and even underscores are ignored:
 **type** is a reserved word, and so is **TYPE** or **T_Y_P_E**. The idea behind
 this is that this allows programmers to use their own preferred spelling style
 and libraries written by different programmers cannot use incompatible
-conventions. A Nimrod-aware editor or IDE can show the identifiers as
+conventions. A Nim-aware editor or IDE can show the identifiers as
 preferred. Another advantage is that it frees the programmer from remembering
 the exact spelling of an identifier.
 
@@ -250,7 +250,7 @@ contain the following `escape sequences`:idx:\ :
 ==================         ===================================================
 
 
-Strings in Nimrod may contain any 8-bit value, even embedded zeros. However 
+Strings in Nim may contain any 8-bit value, even embedded zeros. However 
 some operations may interpret the first binary zero as a terminator.
 
 
@@ -317,7 +317,7 @@ identifier and the opening quotation mark) is a
 generalized raw string literal. It is a shortcut for the construct
 ``identifier(r"string literal")``, so it denotes a procedure call with a
 raw string literal as its only argument. Generalized raw string literals
-are especially convenient for embedding mini languages directly into Nimrod
+are especially convenient for embedding mini languages directly into Nim
 (for example regular expressions).
 
 The construct ``identifier"""string literal"""`` exists too. It is a shortcut
@@ -357,7 +357,7 @@ literals:
 A character is not an Unicode character but a single byte. The reason for this
 is efficiency: for the overwhelming majority of use-cases, the resulting
 programs will still handle UTF-8 properly as UTF-8 was specially designed for
-this. Another reason is that Nimrod can thus support ``array[char, int]`` or
+this. Another reason is that Nim can thus support ``array[char, int]`` or
 ``set[char]`` efficiently as many algorithms rely on this feature.  The `TRune`
 type is used for Unicode characters, it can represent any Unicode character.
 ``TRune`` is declared in the `unicode module <unicode.html>`_.
@@ -441,7 +441,7 @@ is approximately 1.72826e35 according to the IEEE floating point standard.
 Operators
 ---------
 
-In Nimrod one can define his own operators. An operator is any
+In Nim one can define his own operators. An operator is any
 combination of the following characters::
 
        =     +     -     *     /     <     >
@@ -474,10 +474,10 @@ and not the two tokens `{.`:tok:, `.}`:tok:.
 Syntax
 ======
 
-This section lists Nimrod's standard syntax. How the parser handles
+This section lists Nim's standard syntax. How the parser handles
 the indentation is already described in the `Lexical Analysis`_ section.
 
-Nimrod allows user-definable operators.
+Nim allows user-definable operators.
 Binary operators have 10 different levels of precedence.
 
 Relevant character
@@ -588,7 +588,7 @@ The grammar's start symbol is ``module``.
 Types
 =====
 
-All expressions have a type which is known at compile time. Nimrod
+All expressions have a type which is known at compile time. Nim
 is statically typed. One can declare new types, which is in essence defining
 an identifier that can be used to denote this custom type.
 
@@ -686,7 +686,7 @@ kinds of integer types are used: the smaller type is converted to the larger.
 
 A `narrowing type conversion`:idx: converts a larger to a smaller type (for
 example ``int32 -> int16``. A `widening type conversion`:idx: converts a 
-smaller type to a larger type (for example ``int16 -> int32``). In Nimrod only
+smaller type to a larger type (for example ``int16 -> int32``). In Nim only
 widening type conversions are *implicit*:
 
 .. code-block:: nimrod
@@ -723,7 +723,7 @@ determined). Assignments from the base type to one of its subrange types
 
 A subrange type has the same size as its base type (``int`` in the example).
 
-Nimrod requires `interval arithmetic`:idx: for subrange types over a set
+Nim requires `interval arithmetic`:idx: for subrange types over a set
 of built-in operators that involve constants: ``x %% 3`` is of 
 type ``range[0..2]``. The following built-in operators for integers are 
 affected by this rule: ``-``, ``+``, ``*``, ``min``, ``max``, ``succ``,
@@ -781,12 +781,12 @@ The IEEE standard defines five types of floating-point exceptions:
   precision, for example, 2.0 / 3.0, log(1.1) and 0.1 in input.
 
 The IEEE exceptions are either ignored at runtime or mapped to the 
-Nimrod exceptions: `EFloatInvalidOp`:idx:, `EFloatDivByZero`:idx:,
+Nim exceptions: `EFloatInvalidOp`:idx:, `EFloatDivByZero`:idx:,
 `EFloatOverflow`:idx:, `EFloatUnderflow`:idx:, and `EFloatInexact`:idx:. 
 These exceptions inherit from the `EFloatingPoint`:idx: base class.
 
-Nimrod provides the pragmas `NaNChecks`:idx: and `InfChecks`:idx: to control
-whether the IEEE exceptions are ignored or trap a Nimrod exception:
+Nim provides the pragmas `NaNChecks`:idx: and `InfChecks`:idx: to control
+whether the IEEE exceptions are ignored or trap a Nim exception:
 
 .. code-block:: nimrod
   {.NanChecks: on, InfChecks: on.}
@@ -807,7 +807,7 @@ the ``+``, ``-``, ``*``, ``/`` operators for floating point types.
 
 Boolean type
 ------------
-The boolean type is named `bool`:idx: in Nimrod and can be one of the two
+The boolean type is named `bool`:idx: in Nim and can be one of the two
 pre-defined values ``true`` and ``false``. Conditions in while,
 if, elif, when statements need to be of type bool.
 
@@ -831,12 +831,12 @@ The size of the bool type is one byte.
 
 Character type
 --------------
-The character type is named ``char`` in Nimrod. Its size is one byte.
+The character type is named ``char`` in Nim. Its size is one byte.
 Thus it cannot represent an UTF-8 character, but a part of it.
 The reason for this is efficiency: for the overwhelming majority of use-cases,
 the resulting programs will still handle UTF-8 properly as UTF-8 was specially
 designed for this.
-Another reason is that Nimrod can support ``array[char, int]`` or
+Another reason is that Nim can support ``array[char, int]`` or
 ``set[char]`` efficiently as many algorithms rely on this feature. The
 `TRune` type is used for Unicode characters, it can represent any Unicode
 character. ``TRune`` is declared in the `unicode module <unicode.html>`_.
@@ -916,8 +916,8 @@ via ``TMyEnum.value``:
 
 String type
 -----------
-All string literals are of the type ``string``. A string in Nimrod is very
-similar to a sequence of characters. However, strings in Nimrod are both
+All string literals are of the type ``string``. A string in Nim is very
+similar to a sequence of characters. However, strings in Nim are both
 zero-terminated and have a length field. One can retrieve the length with the
 builtin ``len`` procedure; the length never counts the terminating zero.
 The assignment operator for strings always copies the string.
@@ -949,8 +949,8 @@ interfacing with C. The index operation ``s[i]`` means the i-th *char* of
 ``s``; however no bounds checking for ``cstring`` is performed making the
 index operation unsafe.
 
-A Nimrod ``string`` is implicitly convertible 
-to ``cstring`` for convenience. If a Nimrod string is passed to a C-style
+A Nim ``string`` is implicitly convertible 
+to ``cstring`` for convenience. If a Nim string is passed to a C-style
 variadic proc, it is implicitly converted to ``cstring`` too:
 
 .. code-block:: nimrod
@@ -1169,7 +1169,7 @@ An example:
 
 .. code-block:: nimrod
 
-  # This is an example how an abstract syntax tree could be modelled in Nimrod
+  # This is an example how an abstract syntax tree could be modelled in Nim
   type
     TNodeKind = enum  # the different node types
       nkInt,          # a leaf with an integer value
@@ -1230,7 +1230,7 @@ References (similar to pointers in other programming languages) are a
 way to introduce many-to-one relationships. This means different references can
 point to and modify the same location in memory (also called `aliasing`:idx:).
 
-Nimrod distinguishes between `traced`:idx: and `untraced`:idx: references.
+Nim distinguishes between `traced`:idx: and `untraced`:idx: references.
 Untraced references are also called *pointers*. Traced references point to
 objects of a garbage collected heap, untraced references point to
 manually allocated objects or to objects somewhere else in memory. Thus
@@ -1409,7 +1409,7 @@ Future directions:
 Procedural type
 ---------------
 A procedural type is internally a pointer to a procedure. ``nil`` is
-an allowed value for variables of a procedural type. Nimrod uses procedural
+an allowed value for variables of a procedural type. Nim uses procedural
 types to achieve `functional`:idx: programming techniques.
 
 Examples:
@@ -1446,10 +1446,10 @@ compatible if they have the same calling convention. As a special extension,
 a procedure of the calling convention ``nimcall`` can be passed to a parameter
 that expects a proc of the calling convention ``closure``.
 
-Nimrod supports these `calling conventions`:idx:\:
+Nim supports these `calling conventions`:idx:\:
 
 `nimcall`:idx:
-    is the default convention used for a Nimrod **proc**. It is the
+    is the default convention used for a Nim **proc**. It is the
     same as ``fastcall``, but only for C compilers that support ``fastcall``.
 
 `closure`:idx:
@@ -1476,7 +1476,7 @@ Nimrod supports these `calling conventions`:idx:\:
 
 `inline`:idx:
     The inline convention means the the caller should not call the procedure,
-    but inline its code directly. Note that Nimrod does not inline, but leaves
+    but inline its code directly. Note that Nim does not inline, but leaves
     this to the C compiler; it generates ``__inline`` procedures. This is
     only a hint for the compiler: it may completely ignore it and
     it may inline procedures that are not marked as ``inline``.
@@ -1492,7 +1492,7 @@ Nimrod supports these `calling conventions`:idx:\:
 `noconv`:idx:
     The generated C code will not have any explicit calling convention and thus
     use the C compiler's default calling convention. This is needed because
-    Nimrod's default calling convention for procedures is ``fastcall`` to
+    Nim's default calling convention for procedures is ``fastcall`` to
     improve speed.
 
 Most calling conventions exist only for the Windows 32-bit platform.
@@ -1636,7 +1636,7 @@ Currently only the dot accessor can be borrowed in this way.
 Avoiding SQL injection attacks
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-An SQL statement that is passed from Nimrod to an SQL database might be
+An SQL statement that is passed from Nim to an SQL database might be
 modelled as a string. However, using string templates and filling in the
 values is vulnerable to the famous `SQL injection attack`:idx:\:
 
@@ -1745,7 +1745,7 @@ describe the type checking done by the compiler.
 
 Type equality
 -------------
-Nimrod uses structural type equivalence for most types. Only for objects,
+Nim uses structural type equivalence for most types. Only for objects,
 enumerations and distinct types name equivalence is used. The following
 algorithm (in pseudo-code) determines type equality:
 
@@ -1932,7 +1932,7 @@ To be written.
 Statements and expressions
 ==========================
 
-Nimrod uses the common statement/expression paradigm: Statements do not
+Nim uses the common statement/expression paradigm: Statements do not
 produce a value in contrast to expressions. However, some expressions are 
 statements.
 
@@ -2079,7 +2079,7 @@ Const section
 cannot change. The compiler must be able to evaluate the expression in a
 constant declaration at compile time.
 
-Nimrod contains a sophisticated compile-time evaluator, so procedures which
+Nim contains a sophisticated compile-time evaluator, so procedures which
 have no side-effect can be used in constant expressions too:
 
 .. code-block:: nimrod
@@ -2119,7 +2119,7 @@ time.
 
 The current implementation poses some restrictions for compile time
 evaluation: Code which contains ``cast`` or makes use of the foreign function
-interface cannot be evaluated at compile time. Later versions of Nimrod will
+interface cannot be evaluated at compile time. Later versions of Nim will
 support the FFI at compile time.
 
 
@@ -2374,9 +2374,9 @@ Is equivalent to:
 Assembler statement
 -------------------
 
-The direct embedding of assembler code into Nimrod code is supported
+The direct embedding of assembler code into Nim code is supported
 by the unsafe ``asm`` statement. Identifiers in the assembler code that refer to
-Nimrod identifiers shall be enclosed in a special character which can be
+Nim identifiers shall be enclosed in a special character which can be
 specified in the statement's pragmas. The default special character is ``'`'``:
 
 .. code-block:: nimrod
@@ -2425,7 +2425,7 @@ Using statement
 
 The using statement provides syntactic convenience for procs that
 heavily use a single contextual parameter. When applied to a variable or a
-constant, it will instruct Nimrod to automatically consider the used symbol as
+constant, it will instruct Nim to automatically consider the used symbol as
 a hidden leading parameter for any procedure calls, following the using
 statement in the current scope. Thus, it behaves much like the hidden `this`
 parameter available in some object-oriented programming languages.
@@ -2502,7 +2502,7 @@ The `case expression` is again very similar to the case statement:
       "ice cream"
 
 As seen in the above example, the case expression can also introduce side
-effects. When multiple statements are given for a branch, Nimrod will use
+effects. When multiple statements are given for a branch, Nim will use
 the last expression as the result value, much like in an `expr` template.
 
 Table constructor
@@ -2582,7 +2582,7 @@ Procedures
 ==========
 
 What most programming languages call `methods`:idx: or `functions`:idx: are
-called `procedures`:idx: in Nimrod (which is the correct terminology). A
+called `procedures`:idx: in Nim (which is the correct terminology). A
 procedure declaration defines an identifier and associates it with a block
 of code. 
 A procedure may call itself recursively. A parameter may be given a default
@@ -2672,7 +2672,7 @@ postfix notation.
 
 Properties
 ----------
-Nimrod has no need for *get-properties*: Ordinary get-procedures that are called
+Nim has no need for *get-properties*: Ordinary get-procedures that are called
 with the *method call syntax* achieve the same. But setting a value is 
 different; for this a special setter syntax is needed:
 
@@ -2961,7 +2961,7 @@ Invocation of a multi-method cannot be ambiguous: collide 2 is preferred over
 collide 1 because the resolution works from left to right. 
 In the example ``TUnit, TThing`` is preferred over ``TThing, TUnit``.
 
-**Performance note**: Nimrod does not produce a virtual method table, but
+**Performance note**: Nim does not produce a virtual method table, but
 generates dispatch trees. This avoids the expensive indirect branch for method
 calls and enables inlining. However, other optimizations like compile time
 evaluation or dead code elimination do not work with methods.
@@ -3033,7 +3033,7 @@ into account.
 First class iterators
 ---------------------
 
-There are 2 kinds of iterators in Nimrod: *inline* and *closure* iterators.
+There are 2 kinds of iterators in Nim: *inline* and *closure* iterators.
 An `inline iterator`:idx: is an iterator that's always inlined by the compiler 
 leading to zero overhead for the abstraction, but may result in a heavy
 increase in code size. Inline iterators are second class citizens;
@@ -3290,7 +3290,7 @@ Effect system
 Exception tracking
 ------------------
 
-Nimrod supports exception tracking. The `raises`:idx: pragma can be used
+Nim supports exception tracking. The `raises`:idx: pragma can be used
 to explicitly define which exceptions a proc/iterator/method/converter is 
 allowed to raise. The compiler verifies this:
 
@@ -3367,7 +3367,7 @@ conservative in its effect analysis.
 Tag tracking
 ------------
 
-The exception tracking is part of Nimrod's `effect system`:idx:. Raising an
+The exception tracking is part of Nim's `effect system`:idx:. Raising an
 exception is an *effect*. Other effects can also be defined. A user defined 
 effect is a means to *tag* a routine and to perform checks against this tag:
 
@@ -3467,7 +3467,7 @@ Example:
   for str in inorder(root):
     writeln(stdout, str)
 
-Generics are Nimrod's means to parametrize procs, iterators or types with
+Generics are Nim's means to parametrize procs, iterators or types with
 `type parameters`:idx:. Depending on context, the brackets are used either to
 introduce type parameters or to instantiate a generic proc, iterator or type.
 
@@ -3515,7 +3515,7 @@ Type Classes
 
 A type class is a special pseudo-type that can be used to match against
 types in the context of overload resolution or the ``is`` operator. 
-Nimrod supports the following built-in type classes:
+Nim supports the following built-in type classes:
 
 ==================   ===================================================
 type class           matches
@@ -3553,7 +3553,7 @@ Procedures utilizing type classes in such manner are considered to be
 `implicitly generic`:idx:. They will be instantiated once for each unique 
 combination of param types used within the program.
 
-Nimrod also allows for type classes and regular types to be specified
+Nim also allows for type classes and regular types to be specified
 as `type constraints`:idx: of the generic type parameter:
 
 .. code-block:: nimrod
@@ -3579,7 +3579,7 @@ module to illustrate this:
 Alternatively, the ``distinct`` type modifier can be applied to the type class 
 to allow each param matching the type class to bind to a different type. 
 
-If a proc param doesn't have a type specified, Nimrod will use the
+If a proc param doesn't have a type specified, Nim will use the
 ``distinct auto`` type class (also known as ``any``):
 
 .. code-block:: nimrod
@@ -3675,7 +3675,7 @@ Return Type Inference
 ---------------------
 
 If a type class is used as the return type of a proc and it won't be bound to
-a concrete type by some of the proc params, Nimrod will infer the return type
+a concrete type by some of the proc params, Nim will infer the return type
 from the proc body. This is usually used with the ``auto`` type class:
 
 .. code-block:: nimrod
@@ -3684,7 +3684,7 @@ from the proc body. This is usually used with the ``auto`` type class:
 The return type will be treated as additional generic param and can be
 explicitly specified at call sites as any other generic param.
 
-Future versions of Nimrod may also support overloading based on the return type
+Future versions of Nim may also support overloading based on the return type
 of the overloads. In such settings, the expected result type at call sites may 
 also influence the inferred return type.
 
@@ -3760,7 +3760,7 @@ Templates
 =========
 
 A template 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
+mechanism that operates on Nim's abstract syntax trees. It is processed in
 the semantic pass of the compiler.
 
 The syntax to *invoke* a template is the same as calling a procedure.
@@ -3991,10 +3991,10 @@ to implement `domain specific languages`:idx:. Like templates, macros come in
 the 2 flavors *immediate* and *ordinary*.
 
 While macros enable advanced compile-time code transformations, they
-cannot change Nimrod's syntax. However, this is no real restriction because
-Nimrod's syntax is flexible enough anyway.
+cannot change Nim's syntax. However, this is no real restriction because
+Nim's syntax is flexible enough anyway.
 
-To write macros, one needs to know how the Nimrod concrete syntax is converted
+To write macros, one needs to know how the Nim concrete syntax is converted
 to an abstract syntax tree.
 
 There are two ways to invoke a macro:
@@ -4009,12 +4009,12 @@ The following example implements a powerful ``debug`` command that accepts a
 variable number of arguments:
 
 .. code-block:: nimrod
-  # to work with Nimrod syntax trees, we need an API that is defined in the
+  # to work with Nim syntax trees, we need an API that is defined in the
   # ``macros`` module:
   import macros
 
   macro debug(n: varargs[expr]): stmt =
-    # `n` is a Nimrod AST that contains the whole macro invocation
+    # `n` is a Nim AST that contains the whole macro invocation
     # this macro returns a list of statements:
     result = newNimNode(nnkStmtList, n)
     # iterate over any argument that is passed to this macro:
@@ -4313,14 +4313,14 @@ Special Operators
 dot operators
 -------------
 
-Nimrod offers a special family of dot operators that can be used to
+Nim offers a special family of dot operators that can be used to
 intercept and rewrite proc call and field access attempts, referring
 to previously undeclared symbol names. They can be used to provide a
 fluent interface to objects lying outside the static confines of the
 type system such as values from dynamic scripting languages
 or dynamic file formats such as JSON or XML.
 
-When Nimrod encounters an expression that cannot be resolved by the
+When Nim encounters an expression that cannot be resolved by the
 standard overload resolution rules, the current scope will be searched
 for a dot operator that can be matched against a re-written form of
 the expression, where the unknown field or proc name is converted to
@@ -4504,7 +4504,7 @@ is **wrong**:
   echo f() * 2
 
 We cannot duplicate 'a' if it denotes an expression that has a side effect!
-Fortunately Nimrod supports side effect analysis:
+Fortunately Nim supports side effect analysis:
 
 .. code-block:: nimrod
   template optMul{`*`(a, 2)}(a: int{noSideEffect}): int = a+a
@@ -4835,7 +4835,7 @@ optimization for types that have copying semantics:
 
 Modules
 =======
-Nimrod supports splitting a program into pieces by a module concept.
+Nim supports splitting a program into pieces by a module concept.
 Each module needs to be in its own file and has its own `namespace`:idx:.
 Modules enable `information hiding`:idx: and `separate compilation`:idx:.
 A module may gain access to symbols of another module by the `import`:idx:
@@ -5023,7 +5023,7 @@ iterator in which case the overloading resolution takes place:
 Compiler Messages
 =================
 
-The Nimrod compiler emits different kinds of messages: `hint`:idx:,
+The Nim compiler emits different kinds of messages: `hint`:idx:,
 `warning`:idx:, and `error`:idx: messages. An *error* message is emitted if
 the compiler encounters any static error.
 
@@ -5031,7 +5031,7 @@ the compiler encounters any static error.
 Pragmas
 =======
 
-Pragmas are Nimrod's method to give the compiler additional information /
+Pragmas are Nim's method to give the compiler additional information /
 commands without introducing a massive number of new keywords. Pragmas are
 processed on the fly during semantic checking. Pragmas are enclosed in the
 special ``{.`` and ``.}`` curly brackets. Pragmas are also often used as a
@@ -5133,7 +5133,7 @@ shallow pragma
 The ``shallow`` pragma affects the semantics of a type: The compiler is
 allowed to make a shallow copy. This can cause serious semantic issues and
 break memory safety! However, it can speed up assignments considerably, 
-because the semantics of Nimrod require deep copying of sequences and strings. 
+because the semantics of Nim require deep copying of sequences and strings. 
 This can be expensive, especially if sequences are used to build a tree
 structure: 
 
@@ -5223,7 +5223,7 @@ If the ``line`` pragma is used with a parameter, the parameter needs be a
 linearScanEnd pragma
 --------------------
 The ``linearScanEnd`` pragma can be used to tell the compiler how to 
-compile a Nimrod `case`:idx: statement. Syntactically it has to be used as a
+compile a Nim `case`:idx: statement. Syntactically it has to be used as a
 statement:
 
 .. code-block:: nimrod
@@ -5251,7 +5251,7 @@ whole ``case`` statement, the whole ``case`` statement uses linear scanning.
 computedGoto pragma
 -------------------
 The ``computedGoto`` pragma can be used to tell the compiler how to 
-compile a Nimrod `case`:idx: in a ``while true`` statement. 
+compile a Nim `case`:idx: in a ``while true`` statement. 
 Syntactically it has to be used as a statement inside the loop:
 
 .. code-block:: nimrod
@@ -5469,7 +5469,7 @@ Pragma pragma
 -------------
 
 The ``pragma`` pragma can be used to declare user defined pragmas. This is 
-useful because Nimrod's templates and macros do not affect pragmas. User 
+useful because Nim's templates and macros do not affect pragmas. User 
 defined pragmas are in a different module-wide scope than all other symbols. 
 They cannot be imported from a module.
 
@@ -5491,12 +5491,12 @@ generation.
 
 Disabling certain messages
 --------------------------
-Nimrod generates some warnings and hints ("line too long") that may annoy the
+Nim generates some warnings and hints ("line too long") that may annoy the
 user. A mechanism for disabling certain messages is provided: Each hint
 and warning message contains a symbol in brackets. This is the message's
 identifier that can be used to enable or disable it:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   {.hint[LineTooLong]: off.} # turn off the hint about too long lines
 
 This is often better than disabling all warnings at once.
@@ -5505,7 +5505,7 @@ This is often better than disabling all warnings at once.
 Foreign function interface
 ==========================
 
-Nimrod's `FFI`:idx: (foreign function interface) is extensive and only the
+Nim's `FFI`:idx: (foreign function interface) is extensive and only the
 parts that scale to other future backends (like the LLVM/JavaScript backends)
 are documented here.
 
@@ -5514,7 +5514,7 @@ Importc pragma
 --------------
 The ``importc`` pragma provides a means to import a proc or a variable
 from C. The optional argument is a string containing the C identifier. If
-the argument is missing, the C name is the Nimrod identifier *exactly as
+the argument is missing, the C name is the Nim identifier *exactly as
 spelled*:
 
 .. code-block::
@@ -5532,9 +5532,9 @@ Exportc pragma
 The ``exportc`` pragma provides a means to export a type, a variable, or a
 procedure to C. Enums and constants can't be exported. The optional argument
 is a string containing the C identifier.  If the argument is missing, the C
-name is the Nimrod identifier *exactly as spelled*:
+name is the Nim identifier *exactly as spelled*:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   proc callme(formatstr: cstring) {.exportc: "callMe", varargs.}
 
 Note that this pragma is somewhat of a misnomer: Other backends will provide
@@ -5546,7 +5546,7 @@ Extern pragma
 Like ``exportc`` or ``importc``, the ``extern`` pragma affects name
 mangling. The string literal passed to ``extern`` can be a format string:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   proc p(s: string) {.extern: "prefix$1".} =
     echo s
 
@@ -5575,11 +5575,11 @@ the compiler to pass the type by reference (hidden pointer) to procs.
 Varargs pragma
 --------------
 The ``varargs`` pragma can be applied to procedures only (and procedure 
-types). It tells Nimrod that the proc can take a variable number of parameters 
-after the last specified parameter. Nimrod string values will be converted to C
+types). It tells Nim that the proc can take a variable number of parameters 
+after the last specified parameter. Nim string values will be converted to C
 strings automatically:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   proc printf(formatstr: cstring) {.nodecl, varargs.}
 
   printf("hallo %s", "world") # "world" will be passed as C string
@@ -5648,7 +5648,7 @@ With the ``dynlib`` pragma a procedure or a variable can be imported from
 a dynamic library (``.dll`` files for Windows, ``lib*.so`` files for UNIX). 
 The non-optional argument has to be the name of the dynamic library:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   proc gtk_image_new(): PGtkWidget
     {.cdecl, dynlib: "libgtk-x11-2.0.so", importc.}
 
@@ -5706,7 +5706,7 @@ With the ``dynlib`` pragma a procedure can also be exported to
 a dynamic library. The pragma then has no argument and has to be used in
 conjunction with the ``exportc`` pragma:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   proc exportme(): int {.cdecl, exportc, dynlib.}
 
 This is only useful if the program is compiled as a dynamic library via the
@@ -5721,7 +5721,7 @@ be used. The ``system`` module then contains several threading primitives.
 See the `threads <threads.html>`_ and `channels <channels.html>`_ modules 
 for the thread API.
 
-Nimrod's memory model for threads is quite different than that of other common
+Nim's memory model for threads is quite different than that of other common
 programming languages (C, Pascal, Java): Each thread has its own (garbage 
 collected) heap and sharing of memory is restricted to global variables. This 
 helps to prevent race conditions. GC efficiency is improved quite a lot, 
@@ -5797,7 +5797,7 @@ exception in one thread terminates the whole *process*!
 Spawn
 -----
 
-Nimrod has a builtin thread pool that can be used for CPU intensive tasks. For
+Nim has a builtin thread pool that can be used for CPU intensive tasks. For
 IO intensive tasks the upcoming ``async`` and ``await`` features should be
 used instead. `spawn`:idx: is used to pass a task to the thread pool:
 
@@ -5828,7 +5828,7 @@ Currently the expression that ``spawn`` takes is however quite restricted:
 Taint mode
 ==========
 
-The Nimrod compiler and most parts of the standard library support 
+The Nim compiler and most parts of the standard library support 
 a taint mode. Input strings are declared with the `TaintedString`:idx: 
 string type declared in the ``system`` module.
 
diff --git a/doc/nimrodc.txt b/doc/nimrodc.txt
index 016f0ed50..8af045e2e 100644
--- a/doc/nimrodc.txt
+++ b/doc/nimrodc.txt
@@ -1,9 +1,9 @@
 ===================================

-   Nimrod Compiler User Guide

+   Nim Compiler User Guide

 ===================================

 

 :Author: Andreas Rumpf

-:Version: |nimrodversion|

+:Version: |nimversion|

 

 .. contents::

 

@@ -15,11 +15,11 @@
 Introduction

 ============

 

-This document describes the usage of the *Nimrod compiler*

-on the different supported platforms. It is not a definition of the Nimrod

+This document describes the usage of the *Nim compiler*

+on the different supported platforms. It is not a definition of the Nim

 programming language (therefore is the `manual <manual.html>`_).

 

-Nimrod is free software; it is licensed under the

+Nim is free software; it is licensed under the

 `MIT License <http://www.opensource.org/licenses/mit-license.php>`_.

 

 

@@ -107,14 +107,14 @@ Configuration files
 passed as a command line argument to the compiler.

 

 

-The ``nimrod`` executable processes configuration files in the following

+The ``nim`` executable processes configuration files in the following

 directories (in this order; later files overwrite previous settings):

 

-1) ``$nimrod/config/nimrod.cfg``, ``/etc/nimrod.cfg`` (UNIX) or ``%NIMROD%/config/nimrod.cfg`` (Windows). This file can be skipped with the ``--skipCfg`` command line option.

-2) ``/home/$user/.config/nimrod.cfg`` (UNIX) or  ``%APPDATA%/nimrod.cfg`` (Windows). This file can be skipped with the ``--skipUserCfg`` command line option.

-3) ``$parentDir/nimrod.cfg`` where ``$parentDir`` stands for any parent  directory of the project file's path. These files can be skipped with the ``--skipParentCfg`` command line option.

-4) ``$projectDir/nimrod.cfg`` where ``$projectDir`` stands for the project  file's path. This file can be skipped with the ``--skipProjCfg`` command line option.

-5) A project can also have a project specific configuration file named ``$project.nimrod.cfg`` that resides in the same directory as ``$project.nim``. This file can be skipped with the ``--skipProjCfg`` command line option.

+1) ``$nim/config/nim.cfg``, ``/etc/nim.cfg`` (UNIX) or ``%NIMROD%/config/nim.cfg`` (Windows). This file can be skipped with the ``--skipCfg`` command line option.

+2) ``/home/$user/.config/nim.cfg`` (UNIX) or  ``%APPDATA%/nim.cfg`` (Windows). This file can be skipped with the ``--skipUserCfg`` command line option.

+3) ``$parentDir/nim.cfg`` where ``$parentDir`` stands for any parent  directory of the project file's path. These files can be skipped with the ``--skipParentCfg`` command line option.

+4) ``$projectDir/nim.cfg`` where ``$projectDir`` stands for the project  file's path. This file can be skipped with the ``--skipProjCfg`` command line option.

+5) A project can also have a project specific configuration file named ``$project.nim.cfg`` that resides in the same directory as ``$project.nim``. This file can be skipped with the ``--skipProjCfg`` command line option.

 

 

 Command line settings have priority over configuration file settings.

@@ -122,17 +122,17 @@ Command line settings have priority over configuration file settings.
 The default build of a project is a `debug build`:idx:. To compile a 

 `release build`:idx: define the ``release`` symbol::

   

-  nimrod c -d:release myproject.nim

+  nim c -d:release myproject.nim

 
 
 Search path handling
 --------------------
 
-Nimrod has the concept of a global search path (PATH) that is queried to
+Nim has the concept of a global search path (PATH) that is queried to
 determine where to find imported modules or include files. If multiple files are
 found an ambiguity error is produced.
 
-``nimrod dump`` shows the contents of the PATH.
+``nim dump`` shows the contents of the PATH.
 
 However before the PATH is used the current directory is checked for the 
 file's existance. So if PATH contains ``$lib`` and ``$lib/bar`` and the 
@@ -152,10 +152,10 @@ the first matching file is used.
 

 Generated C code directory

 --------------------------

-The generated files that Nimrod produces all go into a subdirectory called
+The generated files that Nim produces all go into a subdirectory called
 ``nimcache`` in your project directory. This makes it easy to delete all
 generated files. Files generated in this directory follow a naming logic which
-you can read about in the `Nimrod Backend Integration document
+you can read about in the `Nim Backend Integration document
 <backends.html#nimcache-naming-logic>`_.
 
 However, the generated C code is not platform independent. C code generated for

@@ -190,14 +190,14 @@ Cross compilation
 

 To cross compile, use for example::

 

-  nimrod c --cpu:i386 --os:linux --compile_only --gen_script myproject.nim

+  nim c --cpu:i386 --os:linux --compile_only --gen_script myproject.nim

 

 Then move the C code and the compile script ``compile_myproject.sh`` to your 

 Linux i386 machine and run the script.
 
-Another way is to make Nimrod invoke a cross compiler toolchain::
+Another way is to make Nim invoke a cross compiler toolchain::
   
-  nimrod c --cpu:arm --os:linux myproject.nim

+  nim c --cpu:arm --os:linux myproject.nim

   
 For cross compilation, the compiler invokes a C compiler named 
 like ``$cpu.$os.$cc`` (for example arm.linux.gcc) and the configuration 
@@ -212,16 +212,16 @@ configuration file should contain something like::
 DLL generation

 ==============

 

-Nimrod supports the generation of DLLs. However, there must be only one 

+Nim supports the generation of DLLs. However, there must be only one 

 instance of the GC per process/address space. This instance is contained in

-``nimrtl.dll``. This means that every generated Nimrod DLL depends

+``nimrtl.dll``. This means that every generated Nim DLL depends

 on ``nimrtl.dll``. To generate the "nimrtl.dll" file, use the command::

   

-  nimrod c -d:release lib/nimrtl.nim

+  nim c -d:release lib/nimrtl.nim

 

 To link against ``nimrtl.dll`` use the command::

 

-  nimrod c -d:useNimRtl myprog.nim

+  nim c -d:useNimRtl myprog.nim

 

 **Note**: Currently the creation of ``nimrtl.dll`` with thread support has 

 never been tested and is unlikely to work!

@@ -243,9 +243,9 @@ Define               Effect
                      version.
 ``useFork``          Makes ``osproc`` use ``fork`` instead of ``posix_spawn``.
 ``useNimRtl``        Compile and link against ``nimrtl.dll``.
-``useMalloc``        Makes Nimrod use C's `malloc`:idx: instead of Nimrod's 
+``useMalloc``        Makes Nim use C's `malloc`:idx: instead of Nim's 
                      own memory manager. This only works with ``gc:none``.
-``useRealtimeGC``    Enables support of Nimrod's GC for *soft* realtime 
+``useRealtimeGC``    Enables support of Nim's GC for *soft* realtime 
                      systems. See the documentation of the `gc <gc.html>`_ 
                      for further information.
 ``nodejs``           The JS target is actually ``node.js``.
@@ -258,8 +258,8 @@ Define               Effect
 Additional Features

 ===================

 

-This section describes Nimrod's additional features that are not listed in the

-Nimrod manual. Some of the features here only make sense for the C code

+This section describes Nim's additional features that are not listed in the

+Nim manual. Some of the features here only make sense for the C code

 generator and are subject to change.

 

 

@@ -267,13 +267,13 @@ NoDecl pragma
 -------------

 The ``noDecl`` pragma can be applied to almost any symbol (variable, proc,

 type, etc.) and is sometimes useful for interoperability with C:

-It tells Nimrod that it should not generate a declaration for the symbol in

+It tells Nim that it should not generate a declaration for the symbol in

 the C code. For example:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   var

     EACCES {.importc, noDecl.}: cint # pretend EACCES was a variable, as

-                                     # Nimrod does not know its value

+                                     # Nim does not know its value

 

 However, the ``header`` pragma is often the better alternative.

 

@@ -286,14 +286,14 @@ The ``header`` pragma is very similar to the ``noDecl`` pragma: It can be
 applied to almost any symbol and specifies that it should not be declared

 and instead the generated code should contain an ``#include``:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   type

     PFile {.importc: "FILE*", header: "<stdio.h>".} = distinct pointer

-      # import C's FILE* type; Nimrod will treat it as a new pointer type

+      # import C's FILE* type; Nim will treat it as a new pointer type

 

 The ``header`` pragma always expects a string constant. The string contant

 contains the header file: As usual for C, a system header file is enclosed

-in angle brackets: ``<>``. If no angle brackets are given, Nimrod

+in angle brackets: ``<>``. If no angle brackets are given, Nim

 encloses the header file in ``""`` in the generated C code.

 

 **Note**: This will not work for the LLVM backend.

@@ -304,7 +304,7 @@ IncompleteStruct pragma
 The ``incompleteStruct`` pragma tells the compiler to not use the 

 underlying C ``struct`` in a ``sizeof`` expression:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   type

     TDIR* {.importc: "DIR", header: "<dirent.h>", 

             final, pure, incompleteStruct.} = object

@@ -315,10 +315,10 @@ Compile pragma
 The ``compile`` pragma can be used to compile and link a C/C++ source file 

 with the project: 

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   {.compile: "myfile.cpp".}

 

-**Note**: Nimrod computes a CRC checksum and only recompiles the file if it 

+**Note**: Nim computes a CRC checksum and only recompiles the file if it 

 has changed. You can use the ``-f`` command line option to force recompilation

 of the file.

 

@@ -327,7 +327,7 @@ Link pragma
 -----------

 The ``link`` pragma can be used to link an additional file with the project: 

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   {.link: "myfile.o".}

 

 

@@ -336,13 +336,13 @@ PassC pragma
 The ``passC`` pragma can be used to pass additional parameters to the C
 compiler like you would using the commandline switch ``--passC``:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   {.passC: "-Wall -Werror".}
 
 Note that you can use ``gorge`` from the `system module <system.html>`_ to
 embed parameters from an external command at compile time:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   {.passC: gorge("pkg-config --cflags sdl").}
 
 PassL pragma
@@ -350,13 +350,13 @@ PassL pragma
 The ``passL`` pragma can be used to pass additional parameters to the linker
 like you would using the commandline switch ``--passL``:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   {.passL: "-lSDLmain -lSDL".}
 
 Note that you can use ``gorge`` from the `system module <system.html>`_ to
 embed parameters from an external command at compile time:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   {.passL: gorge("pkg-config --libs sdl").}
 
 
@@ -369,16 +369,16 @@ extremely useful for interfacing with `C++`:idx: or `Objective C`:idx: code.
 

 Example:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   {.emit: """

   static int cvariable = 420;

   """.}

 

   {.push stackTrace:off.}
   proc embedsC() =

-    var nimrodVar = 89

-    # use backticks to access Nimrod symbols within an emit section:

-    {.emit: """fprintf(stdout, "%d\n", cvariable + (int)`nimrodVar`);""".}

+    var nimVar = 89

+    # use backticks to access Nim symbols within an emit section:

+    {.emit: """fprintf(stdout, "%d\n", cvariable + (int)`nimVar`);""".}

   {.pop.}
 

   embedsC()

@@ -392,7 +392,7 @@ code then uses the C++ method calling syntax: ``obj->method(arg)``.  In
 addition with the ``header`` and ``emit`` pragmas this allows *sloppy*
 interfacing with libraries written in C++:
 

-.. code-block:: Nimrod

+.. code-block:: Nim

   # Horrible example of how to interface with a C++ engine ... ;-)

 

   {.link: "/usr/lib/libIrrlicht.so".}

@@ -431,7 +431,7 @@ generated code then uses the Objective C method calling syntax: ``[obj method
 param1: arg]``.  In addition with the ``header`` and ``emit`` pragmas this
 allows *sloppy* interfacing with libraries written in Objective C:
 

-.. code-block:: Nimrod

+.. code-block:: Nim

   # horrible example of how to interface with GNUStep ...

 

   {.passL: "-lobjc".}

@@ -475,11 +475,11 @@ emits Objective C code.
 CodegenDecl pragma
 ------------------
 
-The ``codegenDecl`` pragma can be used to directly influence Nimrod's code
+The ``codegenDecl`` pragma can be used to directly influence Nim's code
 generator. It receives a format string that determines how the variable or 
 proc is declared in the generated code:
 
-.. code-block:: nimrod
+.. code-block:: nim
   var
     a {.codegenDecl: "$# progmem $#".}: int
 
@@ -494,7 +494,7 @@ The ``injectStmt`` pragma can be used to inject a statement before every
 other statement in the current module. It is only supposed to be used for
 debugging:
 
-.. code-block:: nimrod
+.. code-block:: nim
   {.injectStmt: gcInvariants().}
   
   # ... complex code here that produces crashes ...
@@ -523,7 +523,7 @@ is raised.
 

 Debugger option

 ---------------

-The ``debugger`` option enables or disables the *Embedded Nimrod Debugger*.

+The ``debugger`` option enables or disables the *Embedded Nim Debugger*.

 See the documentation of endb_ for further information.

 

 

@@ -545,11 +545,11 @@ in C/C++).
 Source code style
 =================
 
-Nimrod allows you to `mix freely case and underscores as identifier separators
+Nim allows you to `mix freely case and underscores as identifier separators
 <manual.html#identifiers-keywords>`_, so variables named ``MyPrecioussInt`` and
 ``my_preciouss_int`` are equivalent:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   var MyPrecioussInt = 3
   # Following line compiles fine!
   echo my_preciouss_int
@@ -557,16 +557,16 @@ Nimrod allows you to `mix freely case and underscores as identifier separators
 Since this can lead to many variants of the same source code (you can use
 `nimgrep <nimgrep.html>`_ instead of your typical ``grep`` to ignore style
 problems) the compiler provides the command ``pretty`` to help unifying the
-style of source code.  Running ``nimrod pretty ugly_test.nim`` with this
+style of source code.  Running ``nim pretty ugly_test.nim`` with this
 example will generate a secondary file named ``ugly_test.pretty.nim`` with the
 following content:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   var MyPrecioussInt = 3
   # Following line compiles fine!
   echo MyPrecioussInt
 
-During execution the ``pretty`` command will also run on Nimrod's standard
+During execution the ``pretty`` command will also run on Nim's standard
 library, since it doesn't differentiate the standard library as something
 special, and hence will warn of many *errors* which are out of your hand to
 fix, creating respective ``.pretty.nim`` files all the way. You can ignore
@@ -583,11 +583,11 @@ important changes for you to review. In this case the command is warning that a
 variable name should not start with a capital letter, which is usually reserved
 to `object types <tut2.html#objects>`_. To learn about the accepted `camel case
 style <https://en.wikipedia.org/wiki/Camelcase>`_ read `Coding Guidelines in
-the Internals of Nimrod Compiler <intern.html#coding-guidelines>`_ or `Coding
-Guidelines <https://github.com/Araq/Nimrod/wiki/Coding-Guidelines>`_ and `NEP 1
-: Style Guide for Nimrod Code
-<https://github.com/Araq/Nimrod/wiki/NEP-1-:-Style-Guide-for-Nimrod-Code>`_
-from the Nimrod `GitHub wiki<https://github.com/Araq/Nimrod/wiki>`_.
+the Internals of Nim Compiler <intern.html#coding-guidelines>`_ or `Coding
+Guidelines <https://github.com/Araq/Nim/wiki/Coding-Guidelines>`_ and `NEP 1
+: Style Guide for Nim Code
+<https://github.com/Araq/Nim/wiki/NEP-1-:-Style-Guide-for-Nim-Code>`_
+from the Nim `GitHub wiki<https://github.com/Araq/Nim/wiki>`_.
 
 This command is safe to run because it will never attempt to overwrite your
 existing sources, but the respective ``.pretty.nim`` files **will** be
@@ -597,14 +597,14 @@ overwritten without notice.
 DynlibOverride
 ==============
 
-By default Nimrod's ``dynlib`` pragma causes the compiler to generate 
+By default Nim's ``dynlib`` pragma causes the compiler to generate 
 ``GetProcAddress`` (or their Unix counterparts)
 calls to bind to a DLL. With the ``dynlibOverride`` command line switch this
 can be prevented and then via ``--passL`` the static library can be linked
 against. For instance, to link statically against Lua this command might work
 on Linux::
 
-  nimrod c --dynlibOverride:lua --passL:liblua.lib program.nim
+  nim c --dynlibOverride:lua --passL:liblua.lib program.nim
 
 
 Backend language options
@@ -614,32 +614,32 @@ The typical compiler usage involves using the ``compile`` or ``c`` command to
 transform a ``.nim`` file into one or more ``.c`` files which are then
 compiled with the platform's C compiler into a static binary. However there
 are other commands to compile to C++, Objective-C or Javascript. More details
-can be read in the `Nimrod Backend Integration document <backends.html>`_.
+can be read in the `Nim Backend Integration document <backends.html>`_.
 
 
-Nimrod documentation tools
-==========================
+Nim documentation tools
+=======================
 
-Nimrod provides the `doc`:idx: and `doc2`:idx: commands to generate HTML
+Nim provides the `doc`:idx: and `doc2`:idx: commands to generate HTML
 documentation from ``.nim`` source files. Only exported symbols will appear in
 the output. For more details `see the docgen documentation <docgen.html>`_.
 
-Nimrod idetools integration

-===========================

+Nim idetools integration

+========================

 

-Nimrod provides language integration with external IDEs through the

+Nim provides language integration with external IDEs through the

 idetools command. See the documentation of `idetools <idetools.html>`_

 for further information.

 

 

-Nimrod interactive mode

-=======================

+Nim interactive mode

+====================

 

-The Nimrod compiler supports an interactive mode. This is also known as

-a `REPL`:idx: (*read eval print loop*). If Nimrod has been built with the 

+The Nim compiler supports an interactive mode. This is also known as

+a `REPL`:idx: (*read eval print loop*). If Nim has been built with the 

 ``-d:useGnuReadline`` switch, it uses the GNU readline library for terminal

-input management. To start Nimrod in interactive mode use the command 

-``nimrod i``. To quit use the ``quit()`` command. To determine whether an input

+input management. To start Nim in interactive mode use the command 

+``nim i``. To quit use the ``quit()`` command. To determine whether an input

 line is an incomplete statement to be continued these rules are used:

 

 1. The line ends with ``[-+*/\\<>!\?\|%&$@~,;:=#^]\s*$`` (operator symbol followed by optional whitespace).

@@ -648,8 +648,8 @@ line is an incomplete statement to be continued these rules are used:
    does not work if the line contains more than one ``"""``.

 
 
-Nimrod for embedded systems
-===========================
+Nim for embedded systems
+========================
 
 The standard library can be avoided to a point where C code generation 
 for 16bit micro controllers is feasible. Use the `standalone`:idx: target
@@ -661,7 +661,7 @@ target.
 
 For example, to generate code for an `AVR`:idx: processor use this command::
   
-  nimrod c --cpu:avr --os:standalone --deadCodeElim:on --genScript x.nim
+  nim c --cpu:avr --os:standalone --deadCodeElim:on --genScript x.nim
 
 For the ``standalone`` target you need to provide 
 a file ``panicoverride.nim``. 
@@ -669,27 +669,27 @@ See ``tests/manyloc/standalone/panicoverride.nim`` for an example
 implementation.
 

 
-Nimrod for realtime systems
-===========================
+Nim for realtime systems
+========================
 
-See the documentation of Nimrod's soft realtime `GC <gc.html>`_ for further 
+See the documentation of Nim's soft realtime `GC <gc.html>`_ for further 
 information.
 
 

-Debugging with Nimrod

-=====================

+Debugging with Nim

+==================

 

-Nimrod comes with its own *Embedded Nimrod Debugger*. See

+Nim comes with its own *Embedded Nim Debugger*. See

 the documentation of endb_ for further information.

 

 

-Optimizing for Nimrod

-=====================

+Optimizing for Nim

+==================

 

-Nimrod has no separate optimizer, but the C code that is produced is very

+Nim has no separate optimizer, but the C code that is produced is very

 efficient. Most C compilers have excellent optimizers, so usually it is

-not needed to optimize one's code. Nimrod has been designed to encourage

-efficient code: The most readable code in Nimrod is often the most efficient

+not needed to optimize one's code. Nim has been designed to encourage

+efficient code: The most readable code in Nim is often the most efficient

 too.

 

 However, sometimes one has to optimize. Do it in the following order:

@@ -706,32 +706,32 @@ This section can only help you with the last item.
 Optimizing string handling

 --------------------------

 

-String assignments are sometimes expensive in Nimrod: They are required to

+String assignments are sometimes expensive in Nim: They are required to

 copy the whole string. However, the compiler is often smart enough to not copy

 strings. Due to the argument passing semantics, strings are never copied when

 passed to subroutines. The compiler does not copy strings that are a result from

 a procedure call, because the callee returns a new string anyway.

 Thus it is efficient to do:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   var s = procA() # assignment will not copy the string; procA allocates a new

                   # string already

 

 However it is not efficient to do:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   var s = varA    # assignment has to copy the whole string into a new buffer!

 

 For ``let`` symbols a copy is not always necessary:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   let s = varA    # may only copy a pointer if it safe to do so

 

 

 If you know what you're doing, you can also mark single string (or sequence)

 objects as `shallow`:idx:\:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   var s = "abc"

   shallow(s) # mark 's' as shallow string

   var x = s  # now might not copy the string!

@@ -744,7 +744,7 @@ The compiler optimizes string case statements: A hashing scheme is used for them
 if several different string constants are used. So code like this is reasonably

 efficient:

 

-.. code-block:: Nimrod

+.. code-block:: Nim

   case normalize(k.key)

   of "name": c.name = v

   of "displayname": c.displayName = v