Nimrod renamed to Nim

doc/advopt.txt

@@ -50,7 +50,7 @@ Advanced options:
   --os:SYMBOL               set the target operating system (cross-compilation)
   --cpu:SYMBOL              set the target processor (cross-compilation)
   --debuginfo               enables debug information
-  --debugger:on|off         turn Embedded Nimrod Debugger on|off
+  --debugger:on|off         turn Embedded Nim Debugger on|off
   -t, --passC:OPTION        pass an option to the C compiler
   -l, --passL:OPTION        pass an option to the linker
   --cincludes:DIR           modify the C compiler header search path
@@ -58,7 +58,7 @@ Advanced options:
   --clib:LIBNAME            link an additional C library
                             (you should omit platform-specific extensions)
   --genMapping              generate a mapping file containing
-                            (Nimrod, mangled) identifier pairs
+                            (Nim, mangled) identifier pairs
   --project                 document the whole project (doc2)
   --docSeeSrcUrl:url        activate 'see source' for doc and doc2 commands
                             (see doc.item.seesrc in config/nimdoc.cfg)
@@ -89,7 +89,7 @@ Advanced options:
   --listCmd                 list the commands used to execute external programs
   --parallelBuild=0|1|...   perform a parallel build
                             value = number of processors (0 for auto-detect)
-  --verbosity:0|1|2|3       set Nimrod's verbosity level (1 is default)
+  --verbosity:0|1|2|3       set Nim's verbosity level (1 is default)
   --cs:none|partial         set case sensitivity level (default: none);
                             do not use! this setting affects the whole language
   -v, --version             show detailed version information

doc/apis.txt

@@ -84,5 +84,5 @@ indentation             indent
 Coding Guidelines
 =================
 
-For coding guidelines see the `Internals of the Nimrod Compiler
+For coding guidelines see the `Internals of the Nim Compiler
 <intern.html#coding-guidelines>`_ documentation.

doc/astspec.txt

@@ -1,11 +1,11 @@
-The AST in Nimrod
+The AST in Nim
 =================
-This section describes how the AST is modelled with Nimrod's type system.
+This section describes how the AST is modelled with Nim's type system.
 The AST consists of nodes (``PNimrodNode``) with a variable number of
 children. Each node has a field named ``kind`` which describes what the node
 contains:
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   type
     TNimrodNodeKind = enum ## kind of a node; only explanatory
@@ -39,7 +39,7 @@ contains:
 For the ``PNimrodNode`` type, the ``[]`` operator has been overloaded:
 ``n[i]`` is ``n``'s ``i``-th child.
 
-To specify the AST for the different Nimrod constructs, the notation
+To specify the AST for the different Nim constructs, the notation
 ``nodekind(son1, son2, ...)`` or ``nodekind(value)`` or 
 ``nodekind(field=value)`` is used.
 
@@ -53,7 +53,7 @@ A leaf of the AST often corresponds to a terminal symbol in the concrete
 syntax.
 
 -----------------                ---------------------------------------------
-Nimrod expression                corresponding AST
+Nim expression                   corresponding AST
 -----------------                ---------------------------------------------
 ``42``                           ``nnkIntLit(intVal = 42)``
 ``42'i8``                        ``nnkInt8Lit(intVal = 42)``
@@ -87,12 +87,12 @@ Command call
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   echo "abc", "xyz"
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkCommand(nnkIdent(!"echo"), nnkStrLit("abc"), nnkStrLit("xyz"))
 
 
@@ -101,12 +101,12 @@ Call with ``()``
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   echo("abc", "xyz")
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkCall(nnkIdent(!"echo"), nnkStrLit("abc"), nnkStrLit("xyz"))
 
 
@@ -115,12 +115,12 @@ Infix operator call
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   "abc" & "xyz"
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkInfix(nnkIdent(!"&"), nnkStrLit("abc"), nnkStrLit("xyz"))
 
 
@@ -129,29 +129,29 @@ Prefix operator call
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   ? "xyz"
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkPrefix(nnkIdent(!"?"), nnkStrLit("abc"))
 
 
 Postfix operator call
 ---------------------
 
-**Note:** There are no postfix operators in Nimrod. However, the 
+**Note:** There are no postfix operators in Nim. However, the 
 ``nnkPostfix`` node is used for the *asterisk export marker* ``*``:
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   identifier*
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkPostfix(nnkIdent(!"*"), nnkIdent(!"identifier"))
 
 
@@ -160,12 +160,12 @@ Call with named arguments
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   writeln(file=stdout, "hallo")
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkCall(nnkIdent(!"writeln"), 
           nnkExprEqExpr(nnkIdent(!"file"), nnkIdent(!"stdout")), 
           nnkStrLit("hallo"))
@@ -176,12 +176,12 @@ Dereference operator ``^``
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   x^
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkDerefExpr(nnkIdent(!"x"))
 
 
@@ -190,12 +190,12 @@ Addr operator
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   addr(x)
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkAddr(nnkIdent(!"x"))
 
 
@@ -204,12 +204,12 @@ Cast operator
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   cast[T](x)
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkCast(nnkIdent(!"T"), nnkIdent(!"x"))
 
 
@@ -218,12 +218,12 @@ Object access operator ``.``
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   x.y
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkDotExpr(nnkIdent(!"x"), nnkIdent(!"y"))
 
 
@@ -232,12 +232,12 @@ Array access operator ``[]``
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   x[y]
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkBracketExpr(nnkIdent(!"x"), nnkIdent(!"y"))
 
 
@@ -249,12 +249,12 @@ are built with the ``nnkPar`` node.
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   (1, 2, (3))
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkPar(nnkIntLit(1), nnkIntLit(2), nnkPar(nnkIntLit(3)))
   
   
@@ -265,12 +265,12 @@ Curly braces are used as the set constructor.
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   {1, 2, 3}
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkCurly(nnkIntLit(1), nnkIntLit(2), nnkIntLit(3))
 
 
@@ -281,12 +281,12 @@ Brackets are used as the array constructor.
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   [1, 2, 3]
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkBracket(nnkIntLit(1), nnkIntLit(2), nnkIntLit(3))
 
 
@@ -297,12 +297,12 @@ Ranges occur in set constructors, case statement branches or array slices.
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   1..3
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkRange(nnkIntLit(1), nnkIntLit(3))
 
 
@@ -313,12 +313,12 @@ The representation of the if expression is subtle, but easy to traverse.
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   if cond1: expr1 elif cond2: expr2 else: expr3
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkIfExpr(
     nnkElifExpr(cond1, expr1),
     nnkElifExpr(cond2, expr2),
@@ -337,7 +337,7 @@ there is no ``else`` branch, no ``nnkElse`` child exists.
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   if cond1: 
     stmt1
   elif cond2:
@@ -349,7 +349,7 @@ Concrete syntax:
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkIfStmt(
     nnkElifBranch(cond1, stmt1),
     nnkElifBranch(cond2, stmt2),
@@ -369,12 +369,12 @@ Assignment
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   x = 42
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkAsgn(nnkIdent(!"x"), nnkIntLit(42))
 
 
@@ -383,14 +383,14 @@ Statement list
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   stmt1
   stmt2
   stmt3
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkStmtList(stmt1, stmt2, stmt3)
 
   
@@ -399,7 +399,7 @@ Case statement
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   case expr1
   of expr2, expr3..expr4: 
     stmt1
@@ -412,7 +412,7 @@ Concrete syntax:
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkCaseStmt(
     expr1,
     nnkOfBranch(expr2, nnkRange(expr3, expr4), stmt1),
@@ -429,13 +429,13 @@ While statement
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   while expr1:
     stmt1
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkWhileStmt(expr1, stmt1)
 
 
@@ -444,13 +444,13 @@ For statement
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   for ident1, ident2 in expr1:
     stmt1
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkForStmt(ident1, ident2, expr1, stmt1)
 
 
@@ -459,7 +459,7 @@ Try statement
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   try:
     stmt1
   except e1, e2: 
@@ -473,7 +473,7 @@ Concrete syntax:
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkTryStmt(
     stmt1, 
     nnkExceptBranch(e1, e2, stmt2), 
@@ -488,12 +488,12 @@ Return statement
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   return expr1
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkReturnStmt(expr1)
 
 
@@ -514,12 +514,12 @@ Continue statement
 
 Concrete syntax:
 
-.. code-block:: nimrod
+.. code-block:: nim
   continue
 
 AST:
 
-.. code-block:: nimrod
+.. code-block:: nim
   nnkContinueStmt()
 
 Var section

doc/backends.txt

@@ -1,9 +1,9 @@
 ================================
-   Nimrod Backend Integration
+   Nim Backend Integration
 ================================
 
 :Author: Puppet Master
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
   "Heresy grows from idleness." -- Unknown.
@@ -12,20 +12,20 @@
 Introduction
 ============
 
-The `Nimrod Compiler User Guide <nimrodc.html>`_ documents the typical
+The `Nim Compiler User Guide <nimc.html>`_ documents the typical
 compiler invocation, 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. This document tries to
 concentrate in a single place all the backend and interfacing options.
 
-The Nimrod compiler supports mainly two backend families: the C, C++ and
+The Nim compiler supports mainly two backend families: the C, C++ and
 Objective-C targets and the JavaScript target. `The C like targets`_ creates
 source files which can be compiled into a library or a final executable. `The
 JavaScript target`_ can generate a ``.js`` file which you reference from an
 HTML file or create a `standalone nodejs program <http://nodejs.org>`_.
 
-On top of generating libraries or standalone applications, Nimrod offers
+On top of generating libraries or standalone applications, Nim offers
 bidirectional interfacing with the backend targets through generic and
 specific pragmas.
 
@@ -49,25 +49,25 @@ project.  This allows you to take the generated code and place it directly
 into a project using any of these languages. Here are some typical command
 line invocations::
 
-    $ nimrod c hallo.nim
+    $ nim c hallo.nim
-    $ nimrod cpp hallo.nim
+    $ nim cpp hallo.nim
-    $ nimrod objc hallo.nim
+    $ nim objc hallo.nim
 
 The compiler commands select the target backend, but if needed you can
 `specify additional switches for cross compilation
-<nimrodc.html#cross-compilation>`_ to select the target CPU, operative system
+<nimc.html#cross-compilation>`_ to select the target CPU, operative system
 or compiler/linker commands.
 
 
 The JavaScript target
 ---------------------
 
-Nimrod can also generate `JavaScript`:idx: code through the ``js`` command.
+Nim can also generate `JavaScript`:idx: code through the ``js`` command.
 However, the JavaScript code generator is experimental!
 
-Nimrod targets JavaScript 1.5 which is supported by any widely used browser.
+Nim targets JavaScript 1.5 which is supported by any widely used browser.
 Since JavaScript does not have a portable means to include another module,
-Nimrod just generates a long ``.js`` file.
+Nim just generates a long ``.js`` file.
 
 Features or modules that the JavaScript platform does not support are not
 available. This includes:
@@ -83,35 +83,35 @@ However, the modules `strutils <strutils.html>`_, `math <math.html>`_, and
 `times <times.html>`_ are available! To access the DOM, use the `dom
 <dom.html>`_ module that is only available for the JavaScript platform.
 
-To compile a Nimrod module into a ``.js`` file use the ``js`` command; the
+To compile a Nim module into a ``.js`` file use the ``js`` command; the
 default is a ``.js`` file that is supposed to be referenced in an ``.html``
 file. However, you can also run the code with `nodejs`:idx:, a `software
 platform for easily building fast, scalable network applications
 <http://nodejs.org>`_::
 
-  nimrod js -d:nodejs -r examples/hallo.nim
+  nim js -d:nodejs -r examples/hallo.nim
 
 
 Interfacing
 ===========
 
-Nimrod offers bidirectional interfacing with the target backend. This means
+Nim offers bidirectional interfacing with the target backend. This means
-that you can call backend code from Nimrod and Nimrod code can be called by
+that you can call backend code from Nim and Nim code can be called by
 the backend code. Usually the direction of which calls which depends on your
-software architecture (is Nimrod your main program or is Nimrod providing a
+software architecture (is Nim your main program or is Nim providing a
 component?).
 
 
-Nimrod code calling the backend
+Nim code calling the backend
 --------------------------------
 
-Nimrod code can interface with the backend through the `Foreign function
+Nim code can interface with the backend through the `Foreign function
 interface <manual.html#foreign-function-interface>`_ mainly through the
 `importc pragma <manual.html#importc-pragma>`_. The ``importc`` pragma is the
-*generic* way of making backend symbols available in Nimrod and is available
+*generic* way of making backend symbols available in Nim and is available
 in all the target backends (JavaScript too).  The C++ or Objective-C backends
-have their respective `ImportCpp <nimrodc.html#importcpp-pragma>`_ and
+have their respective `ImportCpp <nimc.html#importcpp-pragma>`_ and
-`ImportObjC <nimrodc.html#importobjc-pragma>`_ pragmas to call methods from
+`ImportObjC <nimc.html#importobjc-pragma>`_ pragmas to call methods from
 classes.
 
 Whenever you use any of these pragmas you need to integrate native code into
@@ -121,22 +121,22 @@ JavaScript functions which you are importing with ``importc``.
 
 However, for the C like targets you need to link external code either
 statically or dynamically. The preferred way of integrating native code is to
-use dynamic linking because it allows you to compile Nimrod programs without
+use dynamic linking because it allows you to compile Nim programs without
 the need for having the related development libraries installed. This is done
 through the `dynlib pragma for import
 <manual.html#dynlib-pragma-for-import>`_, though more specific control can be
 gained using the `dynlib module <dynlib.html>`_.
 
-The `dynlibOverride <nimrodc.html#dynliboverride>`_ command line switch allows
+The `dynlibOverride <nimc.html#dynliboverride>`_ command line switch allows
 to avoid dynamic linking if you need to statically link something instead.
-Nimrod wrappers designed to statically link source files can use the `compile
+Nim wrappers designed to statically link source files can use the `compile
-pragma <nimrodc.html#compile-pragma>`_ if there are few sources or providing
+pragma <nimc.html#compile-pragma>`_ if there are few sources or providing
-them along the Nimrod code is easier than using a system library. Libraries
+them along the Nim code is easier than using a system library. Libraries
 installed on the host system can be linked in with the `PassL pragma
-<nimrodc.html#passl-pragma>`_.
+<nimc.html#passl-pragma>`_.
 
 To wrap native code, take a look at the `c2nim tool <c2nim.html>`_ which helps
-with the process of scanning and transforming header files into a Nimrod
+with the process of scanning and transforming header files into a Nim
 interface.
 
 C invocation example
@@ -152,7 +152,7 @@ Create a ``logic.c`` file with the following content:
 
 Create a ``calculator.nim`` file with the following content:
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   {.compile: "logic.c".}
   proc addTwoIntegers(a, b: cint): cint {.importc.}
@@ -160,8 +160,8 @@ Create a ``calculator.nim`` file with the following content:
   when isMainModule:
     echo addTwoIntegers(3, 7)
 
-With these two files in place, you can run ``nimrod c -r calculator.nim`` and
+With these two files in place, you can run ``nim c -r calculator.nim`` and
-the Nimrod compiler will compile the ``logic.c`` file in addition to
+the Nim compiler will compile the ``logic.c`` file in addition to
 ``calculator.nim`` and link both into an executable, which outputs ``10`` when
 run. Another way to link the C file statically and get the same effect would
 be remove the line with the ``compile`` pragma and run the following typical
@@ -169,7 +169,7 @@ Unix commands::
 
     $ gcc -c logic.c
     $ ar rvs mylib.a logic.o
-    $ nimrod c --passL:mylib.a -r calculator.nim
+    $ nim c --passL:mylib.a -r calculator.nim
 
 Just like in this example we pass the path to the ``mylib.a`` library (and we
 could as well pass ``logic.o``) we could be passing switches to link any other
@@ -196,50 +196,50 @@ Create a ``host.html`` file with the following content:
 Create a ``calculator.nim`` file with the following content (or reuse the one
 from the previous section):
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   proc addTwoIntegers(a, b: int): int {.importc.}
 
   when isMainModule:
     echo addTwoIntegers(3, 7)
 
-Compile the Nimrod code to JavaScript with ``nimrod js -o:calculator.js
+Compile the Nim code to JavaScript with ``nim js -o:calculator.js
 calculator.nim`` and open ``host.html`` in a browser. If the browser supports
 javascript, you should see the value ``10``. In JavaScript the `echo proc
 <system.html#echo>`_ will modify the HTML DOM and append the string. Use the
 `dom module <dom.html>`_ for specific DOM querying and modification procs.
 
 
-Backend code calling Nimrod
+Backend code calling Nim
 ---------------------------
 
-Backend code can interface with Nimrod code exposed through the `exportc
+Backend code can interface with Nim code exposed through the `exportc
 pragma <manual.html#exportc-pragma>`_. The ``exportc`` pragma is the *generic*
-way of making Nimrod symbols available to the backends. By default the Nimrod
+way of making Nim symbols available to the backends. By default the Nim
-compiler will mangle all the Nimrod symbols to avoid any name collision, so
+compiler will mangle all the Nim symbols to avoid any name collision, so
-the most significant thing the ``exportc`` pragma does is maintain the Nimrod
+the most significant thing the ``exportc`` pragma does is maintain the Nim
 symbol name, or if specified, use an alternative symbol for the backend in
 case the symbol rules don't match.
 
 The JavaScript target doesn't have any further interfacing considerations
 since it also has garbage collection, but the C targets require you to
-initialize Nimrod's internals, which is done calling a ``NimMain`` function.
+initialize Nim's internals, which is done calling a ``NimMain`` function.
 Also, C code requires you to specify a forward declaration for functions or
 the compiler will asume certain types for the return value and parameters
 which will likely make your program crash at runtime.
 
-The Nimrod compiler can generate a C interface header through the ``--header``
+The Nim compiler can generate a C interface header through the ``--header``
 command line switch. The generated header will contain all the exported
 symbols and the ``NimMain`` proc which you need to call before any other
-Nimrod code.
+Nim code.
 
 
-Nimrod invocation example from C
+Nim invocation example from C
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Create a ``fib.nim`` file with the following content:
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   proc fib(a: cint): cint {.exportc.} =
     if a <= 2:
@@ -263,34 +263,34 @@ Create a ``maths.c`` file with the following content:
   }
 
 Now you can run the following Unix like commands to first generate C sources
-form the Nimrod code, then link them into a static binary along your main C
+form the Nim code, then link them into a static binary along your main C
 program::
 
-  $ nimrod c --noMain --noLinking --header:fib.h fib.nim
+  $ nim c --noMain --noLinking --header:fib.h fib.nim
-  $ gcc -o m -Inimcache -Ipath/to/nimrod/lib nimcache/*.c maths.c
+  $ gcc -o m -Inimcache -Ipath/to/nim/lib nimcache/*.c maths.c
 
-The first command runs the Nimrod compiler with three special options to avoid
+The first command runs the Nim compiler with three special options to avoid
 generating a ``main()`` function in the generated files, avoid linking the
 object files into a final binary, and explicitly generate a header file for C
 integration. All the generated files are placed into the ``nimcache``
 directory. That's why the next command compiles the ``maths.c`` source plus
 all the ``.c`` files form ``nimcache``. In addition to this path, you also
-have to tell the C compiler where to find Nimrod's ``nimbase.h`` header file.
+have to tell the C compiler where to find Nim's ``nimbase.h`` header file.
 
 Instead of depending on the generation of the individual ``.c`` files you can
-also ask the Nimrod compiler to generate a statically linked library::
+also ask the Nim compiler to generate a statically linked library::
 
-  $ nimrod c --app:staticLib --noMain --header fib.nim
+  $ nim c --app:staticLib --noMain --header fib.nim
-  $ gcc -o m -Inimcache -Ipath/to/nimrod/lib libfib.nim.a maths.c
+  $ gcc -o m -Inimcache -Ipath/to/nim/lib libfib.nim.a maths.c
 
-The Nimrod compiler will handle linking the source files generated in the
+The Nim compiler will handle linking the source files generated in the
 ``nimcache`` directory into the ``libfib.nim.a`` static library, which you can
 then link into your C program.  Note that these commands are generic and will
 vary for each system. For instance, on Linux systems you will likely need to
 use ``-ldl`` too to link in required dlopen functionality.
 
 
-Nimrod invocation example from JavaScript
+Nim invocation example from JavaScript
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Create a ``mhost.html`` file with the following content:
@@ -307,7 +307,7 @@ Create a ``mhost.html`` file with the following content:
 Create a ``fib.nim`` file with the following content (or reuse the one
 from the previous section):
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   proc fib(a: cint): cint {.exportc.} =
     if a <= 2:
@@ -315,11 +315,11 @@ from the previous section):
     else:
       result = fib(a - 1) + fib(a - 2)
 
-Compile the Nimrod code to JavaScript with ``nimrod js -o:fib.js fib.nim`` and
+Compile the Nim code to JavaScript with ``nim js -o:fib.js fib.nim`` and
 open ``mhost.html`` in a browser. If the browser supports javascript, you
 should see an alert box displaying the text ``Fib for 9 is 34``. As mentioned
 earlier, JavaScript doesn't require an initialisation call to ``NimMain`` or
-similar function and you can call the exported Nimrod proc directly.
+similar function and you can call the exported Nim proc directly.
 
 
 Nimcache naming logic
@@ -328,17 +328,17 @@ Nimcache naming logic
 The `nimcache`:idx: directory is generated during compilation and will hold
 either temporary or final files depending on your backend target. The default
 name for the directory is ``nimcache`` but you can use the ``--nimcache``
-`compiler switch <nimrodc.html#command-line-switches>`_ to change it.
+`compiler switch <nimc.html#command-line-switches>`_ to change it.
 
 Nimcache and C like targets
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The C like backends will place their temporary ``.c``, ``.cpp`` or ``.m`` files
 in the ``nimcache`` directory. The naming of these files follows the pattern
-``babelPackageName_`` + ``nimrodSource``:
+``babelPackageName_`` + ``nimSource``:
 
 * Filenames for modules imported from `Babel packages
-  <https://github.com/nimrod-code/babel>`_ will end up with
+  <https://github.com/nim-code/babel>`_ will end up with
   ``babelPackageName_module.c``. For example, if you import the
   ``argument_parser`` module from the same name Babel package you
   will end up with a ``argument_parser_argument_parser.c`` file
@@ -375,7 +375,7 @@ Nimcache and the Javascript target
 
 Unless you explicitly use the ``-o:filename.js`` switch as mentioned in the
 previous examples, the compiler will create a ``filename.js`` file in the
-``nimcache`` directory using the name of your input nimrod file. There are no
+``nimcache`` directory using the name of your input nim file. There are no
 other temporary files generated, the output is always a single self contained
 ``.js`` file.
 
@@ -387,38 +387,38 @@ In the previous sections the ``NimMain()`` function reared its head. Since
 JavaScript already provides automatic memory management, you can freely pass
 objects between the two language without problems. In C and derivate languages
 you need to be careful about what you do and how you share memory. The
-previous examples only dealt with simple scalar values, but passing a Nimrod
+previous examples only dealt with simple scalar values, but passing a Nim
-string to C, or reading back a C string in Nimrod already requires you to be
+string to C, or reading back a C string in Nim already requires you to be
 aware of who controls what to avoid crashing.
 
 
 Strings and C strings
 ---------------------
 
-The manual mentions that `Nimrod strings are implicitly convertible to
+The manual mentions that `Nim strings are implicitly convertible to
 cstrings <manual.html#cstring-type>`_ which makes interaction usually
-painless. Most C functions accepting a Nimrod string converted to a
+painless. Most C functions accepting a Nim string converted to a
 ``cstring`` will likely not need to keep this string around and by the time
 they return the string won't be needed any more. However, for the rare cases
-where a Nimrod string has to be preserved and made available to the C backend
+where a Nim string has to be preserved and made available to the C backend
 as a ``cstring``, you will need to manually prevent the string data from being
 freed with `GC_ref <system.html#GC_ref>`_ and `GC_unref
 <system.html#GC_unref>`_.
 
-A similar thing happens with C code invoking Nimrod code which returns a
+A similar thing happens with C code invoking Nim code which returns a
 ``cstring``. Consider the following proc:
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   proc gimme(): cstring {.exportc.} =
     result = "Hey there C code! " & $random(100)
 
-Since Nimrod's garbage collector is not aware of the C code, once the
+Since Nim's garbage collector is not aware of the C code, once the
 ``gimme`` proc has finished it can reclaim the memory of the ``cstring``.
 However, from a practical standpoint, the C code invoking the ``gimme``
-function directly will be able to use it since Nimrod's garbage collector has
+function directly will be able to use it since Nim's garbage collector has
 not had a chance to run *yet*. This gives you enough time to make a copy for
-the C side of the program, as calling any further Nimrod procs *might* trigger
+the C side of the program, as calling any further Nim procs *might* trigger
 garbage collection making the previously returned string garbage. Or maybe you
 are `triggering yourself the collection <gc.html>`_.
 
@@ -426,35 +426,35 @@ are `triggering yourself the collection <gc.html>`_.
 Custom data types
 -----------------
 
-Just like strings, custom data types that are to be shared between Nimrod and
+Just like strings, custom data types that are to be shared between Nim and
 the backend will need careful consideration of who controlls who. If you want
-to hand a Nimrod reference to C code, you will need to use `GC_ref
+to hand a Nim reference to C code, you will need to use `GC_ref
 <system.html#GC_ref>`_ to mark the reference as used, so it does not get
 freed. And for the C backend you will need to expose the `GC_unref
 <system.html#GC_unref>`_ proc to clean up this memory when it is not required
 any more.
 
 Again, if you are wrapping a library which *mallocs* and *frees* data
-structures, you need to expose the appropriate *free* function to Nimrod so
+structures, you need to expose the appropriate *free* function to Nim so
 you can clean it up. And of course, once cleaned you should avoid accessing it
-from Nimrod (or C for that matter). Typically C data structures have their own
+from Nim (or C for that matter). Typically C data structures have their own
 ``malloc_structure`` and ``free_structure`` specific functions, so wrapping
-these for the Nimrod side should be enough.
+these for the Nim side should be enough.
 
 
 Thread coordination
 -------------------
 
-When the ``NimMain()`` function is called Nimrod initializes the garbage
+When the ``NimMain()`` function is called Nim initializes the garbage
 collector to the current thread, which is usually the main thread of your
-application. If your C code later spawns a different thread and calls Nimrod
+application. If your C code later spawns a different thread and calls Nim
 code, the garbage collector will fail to work properly and you will crash.
 
-As long as you don't use the threadvar emulation Nimrod uses native thread
+As long as you don't use the threadvar emulation Nim uses native thread
 variables, of which you get a fresh version whenever you create a thread. You
 can then attach a GC to this thread via
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   setStackBottom(addr(someLocal))
   initGC()

doc/basicopt.txt

@@ -1,11 +1,11 @@
 Usage::
-  nimrod command [options] [projectfile] [arguments]
+  nim command [options] [projectfile] [arguments]
 
 Command:
   //compile, c                compile project with default code generator (C)
   //doc                       generate the documentation for inputfile
   //doc2                      generate the documentation for the whole project
-  //i                         start Nimrod in interactive mode (limited)
+  //i                         start Nim in interactive mode (limited)
 
 Arguments:
   arguments are passed to the program being run (if --run option is selected)

doc/docgen.txt

@@ -1,9 +1,9 @@
 ===================================
-   Nimrod DocGen Tools Guide
+   Nim DocGen Tools Guide
 ===================================
 
 :Author: Erik O'Leary
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
@@ -12,7 +12,7 @@ Introduction
 ============
 
 This document describes the `documentation generation tools`:idx: built into
-the `Nimrod compiler <nimrodc.html>`_, which can generate HTML and JSON output
+the `Nim compiler <nimc.html>`_, which can generate HTML and JSON output
 from input .nim files and projects, as well as HTML and LaTeX from input RST
 (reStructuredText) files. The output documentation will include module
 dependencies (``import``), any top-level documentation comments (##), and
@@ -25,12 +25,12 @@ Documentation Comments
 Any comments which are preceded by a double-hash (##), are interpreted as
 documentation.  Comments are parsed as RST (see `reference
 <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_), providing
-Nimrod module authors the ability to easily generate richly formatted
+Nim module authors the ability to easily generate richly formatted
 documentation with only their well-documented code.
 
 Example:
 
-.. code-block:: nimrod
+.. code-block:: nim
   type TPerson* = object
     ## This type contains a description of a person
     name: string
@@ -45,7 +45,7 @@ This type contains a description of a person
 
 Field documentation comments can be added to fields like so:
 
-.. code-block:: nimrod
+.. code-block:: nim
   var numValues: int ## \
     ## `numValues` stores the number of values
 
@@ -54,15 +54,15 @@ this type would not be generated. Documentation will only be generated for
 *exported* types/procedures/etc.
 
 
-Nimrod file input
+Nim file input
 -----------------
 
 The following examples will generate documentation for the below contrived
-*Nimrod* module, aptly named 'sample.nim'
+*Nim* module, aptly named 'sample.nim'
 
 sample.nim:
 
-.. code-block:: nimrod
+.. code-block:: nim
   ## This module is a sample.
 
   import strutils
@@ -90,7 +90,7 @@ commands. These command take either a single .nim file, outputting a single
 multiple .html files and, optionally, an index file.
 
 The ``doc`` command::
-  nimrod doc sample
+  nim doc sample
 
 Partial Output::
   ...
@@ -99,11 +99,11 @@ Partial Output::
 
 Output can be viewed in full here: `docgen_sample.html <docgen_sample.html>`_.
 The next command, called ``doc2``, is very similar to the ``doc`` command, but
-will be run after the compiler performs semantic checking on the input nimrod
+will be run after the compiler performs semantic checking on the input nim
 module(s), which allows it to process macros.
 
 The ``doc2`` command::
-  nimrod doc2 sample
+  nim doc2 sample
 
 Partial Output::
   ...
@@ -127,7 +127,7 @@ Note that this tool is built off of the ``doc`` command, and therefore is
 performed before semantic checking.
 
 The ``jsondoc`` command::
-  nimrod jsondoc sample
+  nim jsondoc sample
 
 Output::
   [
@@ -150,9 +150,9 @@ Project switch
 --------------
 
 ::
-  nimrod doc2 --project filename.nim
+  nim doc2 --project filename.nim
 
-This will recursively generate documentation of all nimrod modules imported
+This will recursively generate documentation of all nim modules imported
 into the input module, including system modules. Be careful with this command,
 as it may end up sprinkling html files all over your filesystem!
 
@@ -161,15 +161,15 @@ Index switch
 ------------
 
 ::
-  nimrod doc2 --index:on filename.nim
+  nim doc2 --index:on filename.nim
 
-This will generate an index of all the exported symbols in the input Nimrod
+This will generate an index of all the exported symbols in the input Nim
 module, and put it into a neighboring file with the extension of ``.idx``. The
 index file is line oriented (newlines have to be escaped). Each line
 represents a tab separated record of several columns, the first two mandatory,
 the rest optional. See the `Index (idx) file format`_ section for details.
 
-Once index files have been generated for one or more modules, the Nimrod
+Once index files have been generated for one or more modules, the Nim
 compiler command ``buildIndex directory`` can be run to go over all the index
 files in the specified directory to generate a `theindex.html <theindex.html>`_
 file.
@@ -178,7 +178,7 @@ See source switch
 -----------------
 
 ::
-  nimrod doc2 --docSeeSrcUrl:txt filename.nim
+  nim doc2 --docSeeSrcUrl:txt filename.nim
 
 When you pass the ``docSeeSrcUrl`` switch to docgen, after each documented item
 in your source code the hyper link *See source* will appear pointing to the
@@ -191,25 +191,25 @@ hyper link to your own code repository. As you will see by the comments in that
 file, the value ``txt`` passed on the command line will be used in the HTML
 template along others like ``$path`` and ``$line``.
 
-In the case of Nimrod's own documentation, the ``txt`` value is just a commit
+In the case of Nim's own documentation, the ``txt`` value is just a commit
-hash to append to a formatted URL to https://github.com/Araq/Nimrod. The
+hash to append to a formatted URL to https://github.com/Araq/Nim. The
 ``tools/nimweb.nim`` helper queries the current git commit hash during doc
 generation, but since you might be working on an unpublished repository, it
-also allows specifying a ``githash`` value in ``web/nimrod.ini`` to force a
+also allows specifying a ``githash`` value in ``web/nim.ini`` to force a
 specific commit in the output.
 
 
 Other Input Formats
 ===================
 
-The *Nimrod compiler* also has support for RST (reStructuredText) files with
+The *Nim compiler* also has support for RST (reStructuredText) files with
 the ``rst2html`` and ``rst2tex`` commands. Documents like this one are
-initially written in a dialect of RST which adds support for nimrod sourcecode
+initially written in a dialect of RST which adds support for nim sourcecode
-highlighting with the ``.. code-block:: nimrod`` prefix. ``code-block`` also
+highlighting with the ``.. code-block:: nim`` prefix. ``code-block`` also
 supports highlighting of C++ and some other c-like languages.
 
 Usage::
-  nimrod rst2html docgen.txt
+  nim rst2html docgen.txt
 
 Output::
   You're reading it!
@@ -272,8 +272,8 @@ symbols in the `system module <system.html>`_.
   `#TSignedInt <system.html#TSignedInt>`_
 * ``var globalRaiseHook: proc (e: ref E_Base): bool {.nimcall.}`` **=>**
   `#globalRaiseHook <system.html#globalRaiseHook>`_
-* ``const NimrodVersion = "0.0.0"`` **=>**
+* ``const NimVersion = "0.0.0"`` **=>**
-  `#NimrodVersion <system.html#NimrodVersion>`_
+  `#NimVersion <system.html#NimVersion>`_
 * ``proc getTotalMem(): int {.rtl, raises: [], tags: [].}`` **=>**
   `#getTotalMem, <system.html#getTotalMem,>`_
 * ``proc len[T](x: seq[T]): int {.magic: "LengthSeq", noSideEffect.}`` **=>**
@@ -304,7 +304,7 @@ but can have up to four (additional columns are ignored). The content of these
 columns is:
 
 1. Mandatory term being indexed. Terms can include quoting according to
-   Nimrod's rules (eg. \`^\` like in `the actors module
+   Nim's rules (eg. \`^\` like in `the actors module
    <actors.html#^,ptr.TChannel[T]>`_).
 2. Base filename plus anchor hyper link (eg.
    ``algorithm.html#*,int,TSortOrder``).
@@ -342,7 +342,7 @@ final index, and TOC entries found in ``.nim`` files are discarded.
 Additional resources
 ====================
 
-`Nimrod Compiler User Guide <nimrodc.html#command-line-switches>`_
+`Nim Compiler User Guide <nimc.html#command-line-switches>`_
 
 `RST Quick Reference
 <http://docutils.sourceforge.net/docs/user/rst/quickref.html>`_

doc/docs.txt

@@ -1,18 +1,18 @@
 The documentation consists of several documents:
 
 - | `Tutorial (part I) <tut1.html>`_
-  | The Nimrod tutorial part one deals with the basics.
+  | The Nim tutorial part one deals with the basics.
 
 - | `Tutorial (part II) <tut2.html>`_
-  | The Nimrod tutorial part two deals with the advanced language constructs.
+  | The Nim tutorial part two deals with the advanced language constructs.
 
 - | `Language Manual <manual.html>`_
-  | The Nimrod manual is a draft that will evolve into a proper specification.
+  | The Nim manual is a draft that will evolve into a proper specification.
 
 - | `Library documentation <lib.html>`_
-  | This document describes Nimrod's standard library.
+  | This document describes Nim's standard library.
 
-- | `Compiler user guide <nimrodc.html>`_
+- | `Compiler user guide <nimc.html>`_
   | The user guide lists command line arguments, special features of the
     compiler, etc.
 
@@ -20,11 +20,11 @@ The documentation consists of several documents:
   | Description of some tools that come with the standard distribution.
 
 - | `GC <gc.html>`_
-  | Additional documentation about Nimrod's GC and how to operate it in a
+  | Additional documentation about Nim's GC and how to operate it in a
   | realtime setting.
 
 - | `Source code filters <filters.html>`_
-  | The Nimrod compiler supports source code filters as a simple yet powerful
+  | The Nim compiler supports source code filters as a simple yet powerful
     builtin templating system.
 
 - | `Term rewriting macros <trmacros.html>`_

doc/effects.txt

@@ -1,5 +1,5 @@
 =====================================================================
-               Side effects in Nimrod
+               Side effects in Nim
 =====================================================================
 
 Note: Side effects are implicit produced values! Maybe they should be
@@ -13,7 +13,7 @@ difficult is the ``newString`` proc: If it is simply wrapped, it
 should not be evaluated at compile time! On other occasions it can
 and should be evaluted:
 
-.. code-block:: nimrod
+.. code-block:: nim
   proc toUpper(s: string): string =
     result = newString(len(s))
     for i in 0..len(s) - 1:

doc/endb.txt

@@ -1,15 +1,15 @@
 ==============================================
-  Embedded Nimrod Debugger (ENDB) User Guide
+  Embedded Nim Debugger (ENDB) User Guide
 ==============================================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
 
-Nimrod comes with a platform independent debugger -
+Nim comes with a platform independent debugger -
-the Embedded Nimrod Debugger (ENDB). The debugger is
+the Embedded Nim Debugger (ENDB). The debugger is
 *embedded* into your executable if it has been
 compiled with the ``--debugger:on`` command line option.
 This also defines the conditional symbol ``ENDB`` for you.
@@ -20,7 +20,7 @@ available for the debugger.
 
 If you start your program the debugger will immediately show
 a prompt on the console. You can now enter a command. The next sections
-deal with the possible commands. As usual in Nimrod in all commands
+deal with the possible commands. As usual in Nim in all commands
 underscores and case do not matter. Optional components of a command
 are listed in brackets ``[...]`` here.
 
@@ -105,7 +105,7 @@ The ``breakpoint`` pragma
 The ``breakpoint`` pragma is syntactically a statement. It can be used
 to mark the *following line* as a breakpoint:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   write("1")
   {.breakpoint: "before_write_2".}
   write("2")
@@ -125,7 +125,7 @@ The ``watchpoint`` pragma
 The ``watchpoint`` pragma is syntactically a statement. It can be used
 to mark a location as a watchpoint:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   var a: array [0..20, int]
   
   {.watchpoint: a[3].}
@@ -141,7 +141,7 @@ is turned on, so you don't need to remove it from your source code after
 debugging.
 
 Due to the primitive implementation watchpoints are even slower than
-breakpoints: After *every* executed Nimrod code line it is checked whether the
+breakpoints: After *every* executed Nim code line it is checked whether the
 location changed.
 
 
@@ -159,7 +159,7 @@ Data Display Commands
       in the current stack frame, use the ``up`` or ``down`` command.
 
     Unfortunately, only inspecting variables is possible at the moment. Maybe
-    a future version will implement a full-blown Nimrod expression evaluator,
+    a future version will implement a full-blown Nim expression evaluator,
     but this is not easy to do and would bloat the debugger's code.
 
     Since displaying the whole data structures is often not needed and

doc/estp.txt

@@ -3,10 +3,10 @@
 ===================================================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 
-Nimrod comes with a platform independent profiler -
+Nim comes with a platform independent profiler -
 the Embedded Stack Trace Profiler (ESTP). The profiler 
 is *embedded* into your executable. To activate the profiler you need to do: 
 
@@ -49,7 +49,7 @@ Example results file
 
 The results file lists stack traces ordered by significance. 
 
-The following example file has been generated by profiling the Nimrod compiler
+The following example file has been generated by profiling the Nim compiler
 itself: It shows that in total 5.4% of the runtime has been spent 
 in ``crcFromRope`` or its children.
 
@@ -74,7 +74,7 @@ often remains mysterious.
     CommandCompileToC
     MainCommand
     HandleCmdLine
-    nimrod
+    nim
   Entry: 1/3391 Calls: 46/4160 = 1.1% [sum: 130; 130/4160 = 3.1%]
     updateCrc32
     newCrcFromRopeAux
@@ -90,7 +90,7 @@ often remains mysterious.
     CommandCompileToC
     MainCommand
     HandleCmdLine
-    nimrod
+    nim
   Entry: 2/3391 Calls: 41/4160 = 0.99% [sum: 171; 171/4160 = 4.1%]
     updateCrc32
     updateCrc32
@@ -107,7 +107,7 @@ often remains mysterious.
     CommandCompileToC
     MainCommand
     HandleCmdLine
-    nimrod
+    nim
   Entry: 3/3391 Calls: 41/4160 = 0.99% [sum: 212; 212/4160 = 5.1%]
     crcFromFile
     writeRopeIfNotEqual
@@ -121,7 +121,7 @@ often remains mysterious.
     CommandCompileToC
     MainCommand
     HandleCmdLine
-    nimrod
+    nim
   Entry: 4/3391 Calls: 41/4160 = 0.99% [sum: 253; 253/4160 = 6.1%]
     updateCrc32
     crcFromFile
@@ -136,7 +136,7 @@ often remains mysterious.
     CommandCompileToC
     MainCommand
     HandleCmdLine
-    nimrod
+    nim
   Entry: 5/3391 Calls: 32/4160 = 0.77% [sum: 285; 285/4160 = 6.9%]
     pop
     newCrcFromRopeAux
@@ -152,7 +152,7 @@ often remains mysterious.
     CommandCompileToC
     MainCommand
     HandleCmdLine
-    nimrod
+    nim
   Entry: 6/3391 Calls: 17/4160 = 0.41% [sum: 302; 302/4160 = 7.3%]
     doOperation
     forAllChildrenAux
@@ -171,7 +171,7 @@ often remains mysterious.
     MainCommand
     HandleCmdLine
     ...
-    nimrod
+    nim
   Entry: 7/3391 Calls: 14/4160 = 0.34% [sum: 316; 316/4160 = 7.6%]
     Contains
     isAccessible

doc/filelist.txt

@@ -1,10 +1,10 @@
-Short description of Nimrod's modules
+Short description of Nim's modules
 -------------------------------------
 
 ==============  ==========================================================
 Module          Description
 ==============  ==========================================================
-nimrod          main module: parses the command line and calls
+nim          main module: parses the command line and calls
                 ``main.MainCommand``
 main            implements the top-level command dispatching
 nimconf         implements the config file reader
@@ -12,8 +12,8 @@ syntaxes        dispatcher for the different parsers and filters
 filter_tmpl     standard template filter (``#! stdtempl``)
 lexbase         buffer handling of the lexical analyser
 lexer           lexical analyser
-parser          Nimrod's parser
+parser          Nim's parser
-renderer        Nimrod code renderer (AST back to its textual form)
+renderer        Nim code renderer (AST back to its textual form)
 options         contains global and local compiler options
 ast             type definitions of the abstract syntax tree (AST) and
                 node constructors
@@ -37,7 +37,7 @@ pragmas         semantic checking of pragmas
 
 idents          implements a general mapping from identifiers to an internal
                 representation (``PIdent``) that is used so that a simple
-                id-comparison suffices to say whether two Nimrod identifiers
+                id-comparison suffices to say whether two Nim identifiers
                 are equivalent
 ropes           implements long strings represented as trees for
                 lazy evaluation; used mainly by the code generators

doc/filters.txt

@@ -40,7 +40,7 @@ Filters can be combined with the ``|`` pipe operator::
 Available filters
 =================
 
-**Hint:** With ``--verbosity:2`` (or higher) Nimrod lists the processed code
+**Hint:** With ``--verbosity:2`` (or higher) Nim lists the processed code
 after each filter application.
 
 Replace filter
@@ -79,19 +79,19 @@ Parameters and their defaults:
 StdTmpl filter
 --------------
 
-The stdtmpl filter provides a simple templating engine for Nimrod. The
+The stdtmpl filter provides a simple templating engine for Nim. The
 filter uses a line based parser: Lines prefixed with a *meta character*
-(default: ``#``) contain Nimrod code, other lines are verbatim. Because
+(default: ``#``) contain Nim code, other lines are verbatim. Because
 indentation-based parsing is not suited for a templating engine, control flow
 statements need ``end X`` delimiters.
 
 Parameters and their defaults:
 
   ``metaChar: char = '#'``
-    prefix for a line that contains Nimrod code
+    prefix for a line that contains Nim code
   
   ``subsChar: char = '$'``
-    prefix for a Nimrod expression within a template line
+    prefix for a Nim expression within a template line
     
   ``conc: string = " & "``
     the operation for concatenation
@@ -130,7 +130,7 @@ Example::
 
 The filter transforms this into:
 
-.. code-block:: nimrod
+.. code-block:: nim
   proc generateHTMLPage(title, currentTab, content: string,
                         tabs: openArray[string]): string = 
     result = ""
@@ -158,7 +158,7 @@ The filter transforms this into:
 Each line that does not start with the meta character (ignoring leading
 whitespace) is converted to a string literal that is added to ``result``. 
 
-The substitution character introduces a Nimrod expression *e* within the
+The substitution character introduces a Nim expression *e* within the
 string literal. *e* is converted to a string with the *toString* operation
 which defaults to ``$``. For strong type checking, set ``toString`` to the
 empty string. *e* must match this PEG pattern::

doc/gc.txt

@@ -1,9 +1,9 @@
 ==========================
-Nimrod's Garbage Collector
+Nim's Garbage Collector
 ==========================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
   "The road to hell is paved with good intentions."
 
@@ -37,7 +37,7 @@ it is necessary to help this analysis with the ``acyclic`` pragma (see
 
 You can also use the ``acyclic`` pragma for data that is cyclic in reality and 
 then break up the cycles explicitly with ``GC_addCycleRoot``. This can be a
-very valuable optimization; the Nimrod compiler itself relies on this 
+very valuable optimization; the Nim compiler itself relies on this 
 optimization trick to improve performance. Note that ``GC_addCycleRoot`` is
 a quick operation; the root is only registered for the next run of the 
 cycle collector.
@@ -49,7 +49,7 @@ Realtime support
 To enable realtime support, the symbol `useRealtimeGC`:idx: needs to be
 defined. With this switch the GC supports the following operations:
 
-.. code-block:: nimrod
+.. code-block:: nim
   proc GC_setMaxPause*(MaxPauseInUs: int)
   proc GC_step*(us: int, strongAdvice = false)
 
@@ -111,7 +111,7 @@ highly specialized environments or for older hardware.
 Keeping track of memory
 -----------------------
 
-If you need to pass around memory allocated by Nimrod to C, you can use the
+If you need to pass around memory allocated by Nim to C, you can use the
 procs ``GC_ref`` and ``GC_unref`` to mark objects as referenced to avoid them
 being freed by the GC. Other useful procs from `system <system.html>`_ you can
 use to keep track of memory are:

doc/idetools.txt

@@ -1,9 +1,9 @@
 ================================
-  Nimrod IDE Integration Guide
+  Nim IDE Integration Guide
 ================================
 
 :Author: Britney Spears
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
@@ -13,17 +13,17 @@
   "yes, I'm the creator" -- Araq, 2013-07-26 19:28:32.
   </p></blockquote>
 
-Nimrod differs from many other compilers in that it is really fast,
+Nim differs from many other compilers in that it is really fast,
 and being so fast makes it suited to provide external queries for
 text editors about the source code being written. Through the
-``idetools`` command of `the compiler <nimrodc.html>`_, any IDE
+``idetools`` command of `the compiler <nimc.html>`_, any IDE
 can query a ``.nim`` source file and obtain useful information like
 definition of symbols or suggestions for completion.
 
 This document will guide you through the available options. If you
 want to look at practical examples of idetools support you can look
 at the test files found in the `Test suite`_ or `various editor
-integrations <https://github.com/Araq/Nimrod/wiki/Editor-Support>`_
+integrations <https://github.com/Araq/Nim/wiki/Editor-Support>`_
 already available.
 
 
@@ -37,11 +37,11 @@ All of the available idetools commands require you to specify a
 query location through the ``--track`` or ``--trackDirty`` switches.
 The general idetools invokations are::
 
-    nimrod idetools --track:FILE,LINE,COL <switches> proj.nim
+    nim idetools --track:FILE,LINE,COL <switches> proj.nim
 
 Or::
 
-    nimrod idetools --trackDirty:DIRTY_FILE,FILE,LINE,COL <switches> proj.nim
+    nim idetools --trackDirty:DIRTY_FILE,FILE,LINE,COL <switches> proj.nim
 
 ``proj.nim``
     This is the main *project* filename. Most of the time you will
@@ -97,7 +97,7 @@ provide the typical *Jump to definition* where a user puts the
 cursor on a symbol or uses the mouse to select it and is redirected
 to the place where the symbol is located.
 
-Since Nimrod is implemented in Nimrod, one of the nice things of
+Since Nim is implemented in Nim, one of the nice things of
 this feature is that any user with an IDE supporting it can quickly
 jump around the standard library implementation and see exactly
 what a proc does, learning about the language and seeing real life
@@ -118,7 +118,7 @@ includes/imports) and when the user starts typing something a
 completion box with different options appears.
 
 However such features are not context sensitive and work simply on
-string matching, which can be problematic in Nimrod especially due
+string matching, which can be problematic in Nim especially due
 to the case insensitiveness of the language (plus underscores as
 separators!).
 
@@ -179,16 +179,16 @@ in the millisecond range, thus being responsive enough for IDEs.
 If you want to start the server using stdin/stdout as communication
 you need to type::
 
-    nimrod serve --server.type:stdin proj.nim
+    nim serve --server.type:stdin proj.nim
 
 If you want to start the server using tcp and a port, you need to type::
 
-    nimrod serve --server.type:tcp --server.port:6000 \
+    nim serve --server.type:tcp --server.port:6000 \
       --server.address:hostname proj.nim
 
 In both cases the server will start up and await further commands.
 The syntax of the commands you can now send to the server is
-practically the same as running the nimrod compiler on the commandline,
+practically the same as running the nim compiler on the commandline,
 you only need to remove the name of the compiler since you are
 already talking to it. The server will answer with as many lines
 of text it thinks necessary plus an empty line to indicate the end
@@ -242,7 +242,7 @@ skConst
 | **Fourth column**: the type of the const value.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     const SOME_SEQUENCE = @[1, 2]
     --> col 2: $MODULE.SOME_SEQUENCE
         col 3: seq[int]
@@ -256,7 +256,7 @@ skEnumField
 | **Fourth column**: enum type grouping other enum fields.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     Open(filename, fmWrite)
     --> col 2: system.TFileMode.fmWrite
         col 3: TFileMode
@@ -270,7 +270,7 @@ skForVar
 | **Fourth column**: type of the var.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc looper(filename = "tests.nim") =
       for letter in filename:
         echo letter
@@ -291,7 +291,7 @@ posterior instances of the iterator.
 | **Fourth column**: signature of the iterator including return type.
 | **Docstring**: docstring if available.
 
-.. code-block:: nimrod
+.. code-block:: nim
     let
       text = "some text"
       letters = toSeq(runes(text))
@@ -307,7 +307,7 @@ skLabel
 | **Fourth column**: always the empty string.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc test(text: string) =
       var found = -1
       block loops:
@@ -323,7 +323,7 @@ skLet
 | **Fourth column**: the type of the let variable.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     let
       text = "some text"
     --> col 2: $MODULE.text
@@ -343,7 +343,7 @@ posterior instances of the macro.
 | **Fourth column**: signature of the macro including return type.
 | **Docstring**: docstring if available.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc testMacro() =
       expect(EArithmetic):
     --> col 2: idetools_api.expect
@@ -379,7 +379,7 @@ This may change in the future.
 | **Fourth column**: signature of the method including return type.
 | **Docstring**: docstring if available.
 
-.. code-block:: nimrod
+.. code-block:: nim
     method eval(e: PExpr): int = quit "to override!"
     method eval(e: PLiteral): int = e.x
     method eval(e: PPlusExpr): int = eval(e.a) + eval(e.b)
@@ -396,7 +396,7 @@ skParam
 | **Fourth column**: the type of the parameter.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc reader(filename = "tests.nim") =
       let text = readFile(filename)
     --> col 2: $MODULE.reader.filename
@@ -420,7 +420,7 @@ returned by idetools returns also the pragmas for the proc.
 | **Fourth column**: signature of the proc including return type.
 | **Docstring**: docstring if available.
 
-.. code-block:: nimrod
+.. code-block:: nim
     Open(filename, fmWrite)
     --> col 2: system.Open
         col 3: proc (var TFile, string, TFileMode, int): bool
@@ -438,7 +438,7 @@ skResult
 | **Fourth column**: the type of the result.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc getRandomValue() : int =
       return 4
     --> col 2: $MODULE.getRandomValue.result
@@ -458,7 +458,7 @@ posterior instances of the template.
 | **Fourth column**: signature of the template including return type.
 | **Docstring**: docstring if available.
 
-.. code-block:: nimrod
+.. code-block:: nim
     let
       text = "some text"
       letters = toSeq(runes(text))
@@ -469,7 +469,7 @@ posterior instances of the template.
 
      Example:
 
-     .. code-block:: nimrod
+     .. code-block:: nim
        let
          numeric = @[1, 2, 3, 4, 5, 6, 7, 8, 9]
          odd_numbers = toSeq(filter(numeric) do (x: int) -> bool:
@@ -485,7 +485,7 @@ skType
 | **Fourth column**: the type.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc writeTempFile() =
       var output: TFile
     --> col 2: system.TFile
@@ -500,7 +500,7 @@ skVar
 | **Fourth column**: the type of the var.
 | **Docstring**: always the empty string.
 
-.. code-block:: nimrod
+.. code-block:: nim
     proc writeTempFile() =
       var output: TFile
       output.open("/tmp/somefile", fmWrite)
@@ -527,8 +527,8 @@ At the moment idetools support is still in development so the test
 suite is not integrated with the main test suite and you have to
 run it manually. First you have to compile the tester::
 
-	$ cd my/nimrod/checkout/tests
+	$ cd my/nim/checkout/tests
-	$ nimrod c testament/caasdriver.nim
+	$ nim c testament/caasdriver.nim
 
 Running the ``caasdriver`` without parameters will attempt to process
 all the test cases in all three operation modes. If a test succeeds
@@ -540,7 +540,7 @@ parameter ``verbose`` to force all output even on successfull tests.
 
 The normal operation mode is called ``ProcRun`` and it involves
 starting a process for each command or query, similar to running
-manually the Nimrod compiler from the commandline. The ``CaasRun``
+manually the Nim compiler from the commandline. The ``CaasRun``
 mode starts a server process to answer all queries. The ``SymbolProcRun``
 mode is used by compiler developers.  This means that running all
 tests involves processing all ``*.txt`` files three times, which

doc/intern.txt

@@ -1,10 +1,10 @@
 =========================================
-    Internals of the Nimrod Compiler
+    Internals of the Nim Compiler
 =========================================
 
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
@@ -14,23 +14,23 @@
 Directory structure
 ===================
 
-The Nimrod project's directory structure is:
+The Nim project's directory structure is:
 
 ============   ==============================================
 Path           Purpose
 ============   ==============================================
 ``bin``        generated binary files
 ``build``      generated C code for the installation
-``compiler``   the Nimrod compiler itself; note that this
+``compiler``   the Nim compiler itself; note that this
                code has been translated from a bootstrapping 
                version written in Pascal, so the code is **not** 
-               a poster child of good Nimrod code
+               a poster child of good Nim code
-``config``     configuration files for Nimrod
+``config``     configuration files for Nim
 ``dist``       additional packages for the distribution
 ``doc``        the documentation; it is a bunch of
                reStructuredText files
-``lib``        the Nimrod library
+``lib``        the Nim library
-``web``        website of Nimrod; generated by ``nimweb``
+``web``        website of Nim; generated by ``nimweb``
                from the ``*.txt`` and ``*.tmpl`` files
 ============   ==============================================
 
@@ -38,26 +38,26 @@ Path           Purpose
 Bootstrapping the compiler
 ==========================
 
-As of version 0.8.5 the compiler is maintained in Nimrod. (The first versions 
+As of version 0.8.5 the compiler is maintained in Nim. (The first versions 
 have been implemented in Object Pascal.) The Python-based build system has 
-been rewritten in Nimrod too.
+been rewritten in Nim too.
 
 Compiling the compiler is a simple matter of running::
 
-  nimrod c koch.nim
+  nim c koch.nim
   ./koch boot
 
 For a release version use::
 
-  nimrod c koch.nim
+  nim c koch.nim
   ./koch boot -d:release
 
 And for a debug version compatible with GDB::
 
-  nimrod c koch.nim
+  nim c koch.nim
   ./koch boot --debuginfo --linedir:on
 
-The ``koch`` program is Nimrod's maintenance script. It is a replacement for
+The ``koch`` program is Nim's maintenance script. It is a replacement for
 make and shell scripting with the advantage that it is much more portable.
 More information about its options can be found in the `koch <koch.html>`_
 documentation.
@@ -80,13 +80,13 @@ See also the `API naming design <apis.html>`_ document.
 Porting to new platforms
 ========================
 
-Porting Nimrod to a new architecture is pretty easy, since C is the most
+Porting Nim to a new architecture is pretty easy, since C is the most
-portable programming language (within certain limits) and Nimrod generates
+portable programming language (within certain limits) and Nim generates
 C code, porting the code generator is not necessary.
 
 POSIX-compliant systems on conventional hardware are usually pretty easy to
 port: Add the platform to ``platform`` (if it is not already listed there),
-check that the OS, System modules work and recompile Nimrod.
+check that the OS, System modules work and recompile Nim.
 
 The only case where things aren't as easy is when the garbage
 collector needs some assembler tweaking to work. The standard
@@ -98,7 +98,7 @@ replace this generic code by some assembler code.
 Runtime type information
 ========================
 
-*Runtime type information* (RTTI) is needed for several aspects of the Nimrod
+*Runtime type information* (RTTI) is needed for several aspects of the Nim
 programming language:
 
 Garbage collection
@@ -108,7 +108,7 @@ Garbage collection
 
 Complex assignments
   Sequences and strings are implemented as
-  pointers to resizeable buffers, but Nimrod requires copying for
+  pointers to resizeable buffers, but Nim requires copying for
   assignments. Apart from RTTI the compiler could generate copy procedures
   for any type that needs one. However, this would make the code bigger and
   the RTTI is likely already there for the GC.
@@ -121,12 +121,12 @@ Look at the file ``lib/system/hti.nim`` for more information.
 The compiler's architecture
 ===========================
 
-Nimrod uses the classic compiler architecture: A lexer/scanner feds tokens to a
+Nim uses the classic compiler architecture: A lexer/scanner feds tokens to a
 parser. The parser builds a syntax tree that is used by the code generator.
 This syntax tree is the interface between the parser and the code generator.
 It is essential to understand most of the compiler's code.
 
-In order to compile Nimrod correctly, type-checking has to be separated from
+In order to compile Nim correctly, type-checking has to be separated from
 parsing. Otherwise generics cannot work.
 
 .. include:: filelist.txt
@@ -172,7 +172,7 @@ Frontend issues
 Methods and type converters
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Nimrod contains language features that are *global*. The best example for that
+Nim contains language features that are *global*. The best example for that
 are multi methods: Introducing a new method with the same name and some 
 compatible object parameter means that the method's dispatcher needs to take
 the new method into account. So the dispatching logic is only completely known
@@ -181,12 +181,12 @@ after the whole program has been translated!
 Other features that are *implicitly* triggered cause problems for modularity 
 too. Type converters fall into this category:
 
-.. code-block:: nimrod
+.. code-block:: nim
   # module A
   converter toBool(x: int): bool =
     result = x != 0
     
-.. code-block:: nimrod
+.. code-block:: nim
   # module B
   import A
   
@@ -254,7 +254,7 @@ turned on".
 
 
 
-Debugging Nimrod's memory management
+Debugging Nim's memory management
 ====================================
 
 The following paragraphs are mostly a reminder for myself. Things to keep
@@ -262,7 +262,7 @@ in mind:
 
 * Segmentation faults can have multiple reasons: One that is frequently
   forgotten is that *stack overflow* can trigger one!
-* If an assertion in Nimrod's memory manager or GC fails, the stack trace
+* If an assertion in Nim's memory manager or GC fails, the stack trace
   keeps allocating memory! Thus a stack overflow may happen, hiding the
   real issue. 
 * What seem to be C code generation problems is often a bug resulting from
@@ -300,7 +300,7 @@ set of pointers - this is called a ``TCellSet`` in the source code.
 Inserting, deleting and searching are done in constant time. However,
 modifying a ``TCellSet`` during traversation leads to undefined behaviour.
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   type
     TCellSet # hidden
 
@@ -340,11 +340,11 @@ Complete traversal is done in this way::
 Further complications
 ---------------------
 
-In Nimrod the compiler cannot always know if a reference
+In Nim the compiler cannot always know if a reference
 is stored on the stack or not. This is caused by var parameters.
 Consider this example:
 
-.. code-block:: Nimrod
+.. code-block:: Nim
   proc setRef(r: var ref TNode) =
     new(r)
 
@@ -380,7 +380,7 @@ Code generation for closures is implemented by `lambda lifting`:idx:.
 Design
 ------
 
-A ``closure`` proc var can call ordinary procs of the default Nimrod calling
+A ``closure`` proc var can call ordinary procs of the default Nim calling
 convention. But not the other way round! A closure is implemented as a
 ``tuple[prc, env]``. ``env`` can be nil implying a call without a closure.
 This means that a call through a closure generates an ``if`` but the 
@@ -393,7 +393,7 @@ Tests with GCC on Amd64 showed that it's really beneficical if the
 Proper thunk generation is harder because the proc that is to wrap
 could stem from a complex expression: 
 
-.. code-block:: nimrod
+.. code-block:: nim
   receivesClosure(returnsDefaultCC[i])
 
 A thunk would need to call 'returnsDefaultCC[i]' somehow and that would require
@@ -405,7 +405,7 @@ to pass a proc pointer around via a generic ``ref`` type.
 
 Example code:
 
-.. code-block:: nimrod
+.. code-block:: nim
   proc add(x: int): proc (y: int): int {.closure.} = 
     return proc (y: int): int = 
       return x + y
@@ -415,7 +415,7 @@ Example code:
 
 This should produce roughly this code:
 
-.. code-block:: nimrod
+.. code-block:: nim
   type
     PEnv = ref object
       x: int # data
@@ -436,7 +436,7 @@ This should produce roughly this code:
 
 Beware of nesting:
 
-.. code-block:: nimrod
+.. code-block:: nim
   proc add(x: int): proc (y: int): proc (z: int): int {.closure.} {.closure.} = 
     return lamba (y: int): proc (z: int): int {.closure.} = 
       return lambda (z: int): int = 
@@ -447,7 +447,7 @@ Beware of nesting:
 
 This should produce roughly this code:
 
-.. code-block:: nimrod
+.. code-block:: nim
   type
     PEnvX = ref object
       x: int # data
@@ -492,7 +492,7 @@ environments. This is however not always possible.
 Accumulator
 -----------
 
-.. code-block:: nimrod
+.. code-block:: nim
   proc GetAccumulator(start: int): proc (): int {.closure} = 
     var i = start
     return lambda: int = 

doc/koch.txt

@@ -1,8 +1,8 @@
 ===============================
-   Nimrod maintenance script
+   Nim maintenance script
 ===============================
 
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
@@ -15,10 +15,10 @@
 Introduction
 ============
 
-The `koch`:idx: program is Nimrod's maintenance script. It is a replacement
+The `koch`:idx: program is Nim's maintenance script. It is a replacement
 for make and shell scripting with the advantage that it is much more portable.
 The word *koch* means *cook* in German. ``koch`` is used mainly to build the
-Nimrod compiler, but it can also be used for other tasks. This document
+Nim compiler, but it can also be used for other tasks. This document
 describes the supported commands and their options.
 
 
@@ -40,21 +40,21 @@ options:
   option is not supported on Windows.
 -d:useGnuReadline
   Includes the `rdstdin module <rdstdin.html>`_ for `interactive
-  mode <nimrodc.html#nimrod-interactive-mode>`_ (aka ``nimrod i``).
+  mode <nimc.html#nim-interactive-mode>`_ (aka ``nim i``).
   This is not needed on Windows. On other platforms this may
   incorporate the GNU readline library.
 -d:nativeStacktrace
   Use native stack traces (only for Mac OS X or Linux).
 -d:noCaas
-  Builds Nimrod without compiler as a service (CAAS) support. CAAS
+  Builds Nim without compiler as a service (CAAS) support. CAAS
-  support is required for functionality like Nimrod's `idetool
+  support is required for functionality like Nim's `idetool
   <idetools.html>`_ command used to integrate the compiler with
-  `external IDEs <https://github.com/Araq/Nimrod/wiki/Editor-Support>`_.
+  `external IDEs <https://github.com/Araq/Nim/wiki/Editor-Support>`_.
 -d:avoidTimeMachine
   Only for Mac OS X, activating this switch will force excluding
   the generated ``nimcache`` directories from Time Machine backups.
   By default ``nimcache`` directories will be included in backups,
-  and just for the Nimrod compiler itself it means backing up 20MB
+  and just for the Nim compiler itself it means backing up 20MB
   of generated files each time you update the compiler. Using this
   option will make the compiler invoke the `tmutil
   <https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/tmutil.8.html>`_
@@ -66,18 +66,18 @@ options:
 
     $ find . -type d -name nimcache -exec tmutil isexcluded \{\} \;
 -d:useFFI
-  Nimrod code can use the `foreign function interface (FFI)
+  Nim code can use the `foreign function interface (FFI)
   <manual.html#foreign-function-interface>`_ at runtime, but macros
-  are limited to pure Nimrod code at compilation time.  Enabling
+  are limited to pure Nim code at compilation time.  Enabling
-  this switch will allow macros to execute non-nimrod code at
+  this switch will allow macros to execute non-nim code at
   compilation time (eg. open a file and write to it).
 --gc:refc|v2|markAndSweep|boehm|none
   Selects which garbage collection strategy to use for the compiler
-  and generated code. See the `Nimrod's Garbage Collector <gc.html>`_
+  and generated code. See the `Nim's Garbage Collector <gc.html>`_
   documentation for more information.
 
-After compilation is finished you will hopefully end up with the nimrod
+After compilation is finished you will hopefully end up with the nim
-compiler in the ``bin`` directory. You can add Nimrod's ``bin`` directory to
+compiler in the ``bin`` directory. You can add Nim's ``bin`` directory to
 your ``$PATH`` or use the `install command`_ to place it where it will be
 found.
 
@@ -101,7 +101,7 @@ The `inno`:idx: command builds the `Inno Setup installer for Windows
 install command
 ---------------
 
-The `install`:idx: command installs Nimrod to the specified directory, which
+The `install`:idx: command installs Nim to the specified directory, which
 is required as a parameter. For example, on Unix platforms you could run::
 
   $ ./koch install /usr/local/bin
@@ -109,8 +109,8 @@ is required as a parameter. For example, on Unix platforms you could run::
 temp command
 ------------
 
-The temp command builds the Nimrod compiler but with a different final name
+The temp command builds the Nim compiler but with a different final name
-(``nimrod_temp``), so it doesn't overwrite your normal compiler. You can use
+(``nim_temp``), so it doesn't overwrite your normal compiler. You can use
 this command to test different options, the same you would issue for the `boot
 command`_.
 
@@ -119,14 +119,14 @@ test command
 
 The `test`:idx: command can also be invoked with the alias ``tests``. This
 command will compile and run ``tests/testament/tester.nim``, which is the main
-driver of Nimrod's test suite. You can pass options to the ``test`` command,
+driver of Nim's test suite. You can pass options to the ``test`` command,
 they will be forwarded to the tester. See its source code for available
 options.
 
 update command
 --------------
 
-The `update`:idx: command updates nimrod to the latest version from github.
+The `update`:idx: command updates nim to the latest version from github.
 For this command to work you need to have compiled ``koch`` itself with the
 ``-d:withUpdate`` switch.
 
@@ -136,7 +136,7 @@ web command
 The `web`:idx: command converts the documentation in the ``doc`` directory
 from rst to HTML. It also repeats the same operation but places the result in
 the ``web/upload`` which can be used to update the website at
-http://nimrod-lang.org.
+http://nim-lang.org.
 
 zip command
 -----------

doc/nimgrep.txt

@@ -10,7 +10,7 @@ Nimgrep is a command line tool for search&replace tasks. It can search for
 regex or peg patterns and can search whole directories at once. User 
 confirmation for every single replace operation can be requested.
 
-Nimgrep has particularly good support for Nimrod's 
+Nimgrep has particularly good support for Nim's 
 eccentric *style insensitivity*. Apart from that it is a generic text 
 manipulation tool.
 
@@ -20,7 +20,7 @@ Installation
 
 Compile nimgrep with the command::
 
-  nimrod c -d:release tools/nimgrep.nim
+  nim c -d:release tools/nimgrep.nim
 
 And copy the executable somewhere in your ``$PATH``.
 

doc/niminst.txt

@@ -3,14 +3,14 @@
 =========================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
 Introduction
 ============
 
-niminst is a tool to generate an installer for a Nimrod program. Currently
+niminst is a tool to generate an installer for a Nim program. Currently
 it can create an installer for Windows 
 via `Inno Setup <http://www.jrsoftware.org/isinfo.php>`_ as well as
 installation/deinstallation scripts for UNIX. Later versions will support 
@@ -24,7 +24,7 @@ systems.
 Configuration file
 ==================
 
-niminst uses the Nimrod `parsecfg <parsecfg.html>`_ module to parse the 
+niminst uses the Nim `parsecfg <parsecfg.html>`_ module to parse the 
 configuration file. Here's an example of how the syntax looks like:
 
 .. include:: doc/mytest.cfg
@@ -187,9 +187,9 @@ Key                    description
 Real world example
 ==================
 
-The installers for the Nimrod compiler itself are generated by niminst. Have a
+The installers for the Nim compiler itself are generated by niminst. Have a
 look at its configuration file:
 
-.. include:: compiler/nimrod.ini
+.. include:: compiler/nim.ini
      :literal:
 

doc/overview.txt

@@ -1,9 +1,9 @@
 =============================
-Nimrod Documentation Overview
+Nim Documentation Overview
 =============================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. include:: ../doc/docs.txt
 

doc/pegdocs.txt

@@ -171,7 +171,7 @@ The PEG parser implements this grammar (written in PEG syntax)::
 expression, identifiers are not interpreted as non-terminals, but are 
 interpreted as verbatim string:
 
-.. code-block:: nimrod
+.. code-block:: nim
   abc =~ peg"abc" # is true
 
 So it is not necessary to write ``peg" 'abc' "`` in the above example.
@@ -182,17 +182,17 @@ Examples
 
 Check if `s` matches Nim's "while" keyword:
 
-.. code-block:: nimrod
+.. code-block:: nim
   s =~ peg" y'while'"
 
 Exchange (key, val)-pairs: 
 
-.. code-block:: nimrod
+.. code-block:: nim
   "key: val; key2: val2".replace(peg"{\ident} \s* ':' \s* {\ident}", "$2: $1")
 
 Determine the ``#include``'ed files of a C file:
 
-.. code-block:: nimrod
+.. code-block:: nim
   for line in lines("myfile.c"):
     if line =~ peg"""s <- ws '#include' ws '"' {[^"]+} '"' ws
                      comment <- '/*' @ '*/' / '//' .*

doc/readme.txt

@@ -1,7 +1,7 @@
 ============================
-Nimrod's documenation system
+Nim's documenation system
 ============================
 
-This folder contains Nimrod's documentation. The documentation
+This folder contains Nim's documentation. The documentation
 is written in a format called *reStructuredText*, a markup language that reads
 like ASCII and can be converted to HTML automatically!

doc/regexprs.txt

@@ -44,9 +44,9 @@ As the regular expressions supported by this module are enormous,
 the reader is referred to http://perldoc.perl.org/perlre.html for the
 full documentation of Perl's regular expressions.
 
-Because the backslash ``\`` is a meta character both in the Nimrod
+Because the backslash ``\`` is a meta character both in the Nim
 programming language and in regular expressions, it is strongly
-recommended that one uses the *raw* strings of Nimrod, so that
+recommended that one uses the *raw* strings of Nim, so that
 backslashes are interpreted by the regular expression engine::
 
   r"\S"  # matches any character that is not whitespace

doc/rst.txt

@@ -1,9 +1,9 @@
 ===========================================================================
-       Nimrod's implementation of |rst|
+       Nim's implementation of |rst|
 ===========================================================================
 
 :Author: Andreas Rumpf
-:Version: |nimrodversion|
+:Version: |nimversion|
 
 .. contents::
 
@@ -11,15 +11,15 @@ Introduction
 ============
 
 This document describes the subset of `Docutils`_' `reStructuredText`_ as it
-has been implemented in the Nimrod compiler for generating documentation.
+has been implemented in the Nim compiler for generating documentation.
 Elements of |rst| that are not listed here have not been implemented.
-Unfortunately, the specification of |rst| is quite vague, so Nimrod is not as
+Unfortunately, the specification of |rst| is quite vague, so Nim is not as
 compatible to the original implementation as one would like.
 
-Even though Nimrod's |rst| parser does not parse all constructs, it is pretty
+Even though Nim's |rst| parser does not parse all constructs, it is pretty
 usable. The missing features can easily be circumvented. An indication of this
-fact is that Nimrod's *whole* documentation itself (including this document) is
+fact is that Nim's *whole* documentation itself (including this document) is
-processed by Nimrod's |rst| parser. (Which is an order of magnitude faster than
+processed by Nim's |rst| parser. (Which is an order of magnitude faster than
 Docutils' parser.)
 
 
@@ -65,19 +65,19 @@ Definition lists
 
 Save this code to the file "greeting.nim". Now compile and run it:
 
-  ``nimrod run greeting.nim``
+  ``nim run greeting.nim``
 
-As you see, with the ``run`` command Nimrod executes the file automatically
+As you see, with the ``run`` command Nim executes the file automatically
 after compilation. You can even give your program command line arguments by
 appending them after the filename that is to be compiled and run:
 
-  ``nimrod run greeting.nim arg1 arg2``
+  ``nim run greeting.nim arg1 arg2``
 
 
 Tables
 ======
 
-Nimrod only implements simple tables of the form::
+Nim only implements simple tables of the form::
 
   ==================      ===============       ===================
   header 1                header 2              header n

doc/sets_fragment.txt

@@ -6,7 +6,7 @@ Sets can be constructed via the set constructor: ``{}`` is the empty set. The
 empty set is type compatible with any concrete set type. The constructor
 can also be used to include elements (and ranges of elements):
 
-.. code-block:: nimrod
+.. code-block:: nim
   type
     TCharSet = set[char]
   var

doc/spawn.txt

@@ -2,7 +2,7 @@
                   Parallel & Spawn
 ==========================================================
 
-Nimrod has two flavors of parallelism: 
+Nim has two flavors of parallelism: 
 1) `Structured`:idx parallelism via the ``parallel`` statement.
 2) `Unstructured`:idx: parallelism via the standalone ``spawn`` statement.
 
@@ -24,7 +24,7 @@ Parallel statement
 
 Example:
 
-.. code-block:: nimrod
+.. code-block:: nim
   # Compute PI in an inefficient way
   import strutils, math, threadpool
 
@@ -42,7 +42,7 @@ Example:
 
 
 The parallel statement is the preferred mechanism to introduce parallelism
-in a Nimrod program. A subset of the Nimrod language is valid within a
+in a Nim program. A subset of the Nim language is valid within a
 ``parallel`` section. This subset is checked to be free of data races at
 compile time. A sophisticated `disjoint checker`:idx: ensures that no data
 races are possible even though shared memory is extensively supported!
@@ -77,7 +77,7 @@ the passed expression on the thread pool and returns a `data flow variable`:idx:
 **blocking**. However, one can use ``awaitAny`` to wait on multiple flow
 variables at the same time:
 
-.. code-block:: nimrod
+.. code-block:: nim
   import threadpool, ...
   
   # wait until 2 out of 3 servers received the update:

doc/subexes.txt

@@ -45,7 +45,7 @@ Notation                meaning
 Examples
 ========
 
-.. code-block:: nimrod
+.. code-block:: nim
 
   subex"$1($', '{2..})" % ["f", "a", "b", "c"] == "f(a, b, c)"
   

doc/tools.txt

@@ -1,20 +1,20 @@
 ===========================
-Tools available with Nimrod
+Tools available with Nim
 ===========================
 
 The standard distribution ships with the following tools:
 
-- | `Nimrod Installation Generator <niminst.html>`_
+- | `Nim Installation Generator <niminst.html>`_
-  | How to generate a nice installer for your Nimrod program.
+  | How to generate a nice installer for your Nim program.
 
 - | `C2nim <c2nim.html>`_
-  | C to Nimrod source converter. Translates C header files to Nimrod.
+  | C to Nim source converter. Translates C header files to Nim.
 
 - | `nimgrep <nimgrep.html>`_
-  | Nimrod search and replace utility.
+  | Nim search and replace utility.
 
 - | `endb <endb.html>`_
-  | Nimrod's slow platform independent embedded debugger.
+  | Nim's slow platform independent embedded debugger.
 
 - | `estp <estp.html>`_
-  | Nimrod's slow platform independent embedded stack trace profiler.
+  | Nim's slow platform independent embedded stack trace profiler.

doc/tut2.txt

@@ -858,7 +858,7 @@ The good news is not much has changed! First, we need to change the handling of
 the input parameter. In the dynamic version the ``readCfgAtRuntime`` proc
 receives a string parameter. However, in the macro version it is also declared
 as string, but this is the *outside* interface of the macro.  When the macro is
-run, it actually gets a ``PNimrodNode`` object instead of a string, and we have
+run, it actually gets a ``PNimNode`` object instead of a string, and we have
 to call the ``strVal`` proc from the `macros module <macros.html>`_ to obtain
 the string being passed in to the macro.
 

readme.md

@@ -1,15 +1,15 @@
-# Nimrod Compiler
+# Nim Compiler
-This repo contains the Nimrod compiler, Nimrod's stdlib, tools and 
+This repo contains the Nim compiler, Nim's stdlib, tools and 
 documentation.
 
 ## Compiling
-Compiling the Nimrod compiler is quite straightforward. Because
+Compiling the Nim compiler is quite straightforward. Because
-the Nimrod compiler itself is written in the Nimrod programming language
+the Nim compiler itself is written in the Nim programming language
 the C source of an older version of the compiler are needed to bootstrap the
-latest version. The C sources are available in a separate repo [here](http://github.com/nimrod-code/csources).
+latest version. The C sources are available in a separate repo [here](http://github.com/nim-code/csources).
 
 Pre-compiled snapshots of the compiler are also available on
-[Nimbuild](http://build.nimrod-lang.org/). Your platform however may not 
+[Nimbuild](http://build.nim-lang.org/). Your platform however may not 
 currently be built for.
 
 The compiler currently supports the following platform and architecture 
@@ -30,16 +30,16 @@ To build from source you will need:
 If you are on a fairly modern *nix system, the following steps should work:
 
 ```
-$ git clone git://github.com/Araq/Nimrod.git
+$ git clone git://github.com/Araq/Nim.git
-$ cd Nimrod
+$ cd Nim
-$ git clone --depth 1 git://github.com/nimrod-code/csources
+$ git clone --depth 1 git://github.com/nim-code/csources
 $ cd csources && sh build.sh
 $ cd ..
-$ bin/nimrod c koch
+$ bin/nim c koch
 $ ./koch boot -d:release
 ```
 
-``koch install [dir]`` may then be used to install Nimrod, or you can simply
+``koch install [dir]`` may then be used to install Nim, or you can simply
 add it to your PATH. More ``koch`` related options are documented in
 [doc/koch.txt](doc/koch.txt).
 
@@ -48,16 +48,16 @@ The above steps can be performed on Windows in a similar fashion, the
 instead of ``build.sh``.
 
 ## Getting help
-A [forum](http://forum.nimrod-lang.org/) is available if you have any
+A [forum](http://forum.nim-lang.org/) is available if you have any
 questions, and you can also get help in the IRC channel on
-[Freenode](irc://irc.freenode.net/nimrod) in #nimrod. If you ask questions on
+[Freenode](irc://irc.freenode.net/nim) in #nim. If you ask questions on
-[StackOverflow use the nimrod
+[StackOverflow use the nim
-tag](http://stackoverflow.com/questions/tagged/nimrod).
+tag](http://stackoverflow.com/questions/tagged/nim).
 
 ## License
 The compiler and the standard library are licensed under the MIT license, 
 except for some modules where the documentation suggests otherwise. This means 
-that you can use any license for your own programs developed with Nimrod, 
+that you can use any license for your own programs developed with Nim, 
 allowing you to create commercial applications.
 
 Read copying.txt for more details.

readme.txt

@@ -1,15 +1,15 @@
-# Nimrod Compiler
+# Nim Compiler
-This repo contains the Nimrod compiler, Nimrod's stdlib, tools and 
+This repo contains the Nim compiler, Nim's stdlib, tools and 
 documentation.
 
 ## Compiling
-Compiling the Nimrod compiler is quite straightforward. Because
+Compiling the Nim compiler is quite straightforward. Because
-the Nimrod compiler itself is written in the Nimrod programming language
+the Nim compiler itself is written in the Nim programming language
 the C source of an older version of the compiler are needed to bootstrap the
-latest version. The C sources are available in a separate repo [here](http://github.com/nimrod-code/csources).
+latest version. The C sources are available in a separate repo [here](http://github.com/nim-code/csources).
 
 Pre-compiled snapshots of the compiler are also available on
-[Nimbuild](http://build.nimrod-lang.org/). Your platform however may not 
+[Nimbuild](http://build.nim-lang.org/). Your platform however may not 
 currently be built for.
 
 The compiler currently supports the following platform and architecture 
@@ -30,16 +30,16 @@ To build from source you will need:
 If you are on a fairly modern *nix system, the following steps should work:
 
 ```
-$ git clone git://github.com/Araq/Nimrod.git
+$ git clone git://github.com/Araq/Nim.git
-$ cd Nimrod
+$ cd Nim
-$ git clone --depth 1 git://github.com/nimrod-code/csources
+$ git clone --depth 1 git://github.com/nim-code/csources
 $ cd csources && ./build.sh
 $ cd ..
-$ bin/nimrod c koch
+$ bin/nim c koch
 $ ./koch boot -d:release
 ```
 
-``koch install [dir]`` may then be used to install Nimrod, or you can simply
+``koch install [dir]`` may then be used to install Nim, or you can simply
 add it to your PATH. More ``koch`` related options are documented in
 [doc/koch.txt](doc/koch.txt).
 
@@ -48,16 +48,16 @@ The above steps can be performed on Windows in a similar fashion, the
 instead of ``build.sh``.
 
 ## Getting help
-A [forum](http://forum.nimrod-lang.org/) is available if you have any
+A [forum](http://forum.nim-lang.org/) is available if you have any
 questions, and you can also get help in the IRC channel on
-[Freenode](irc://irc.freenode.net/nimrod) in #nimrod. If you ask questions on
+[Freenode](irc://irc.freenode.net/nim) in #nim. If you ask questions on
-[StackOverflow use the nimrod
+[StackOverflow use the nim
-tag](http://stackoverflow.com/questions/tagged/nimrod).
+tag](http://stackoverflow.com/questions/tagged/nim).
 
 ## License
 The compiler and the standard library are licensed under the MIT license, 
 except for some modules where the documentation suggests otherwise. This means 
-that you can use any license for your own programs developed with Nimrod, 
+that you can use any license for your own programs developed with Nim, 
 allowing you to create commercial applications.
 
 Read copying.txt for more details.