diff --git a/doc/docgen.txt b/doc/docgen.txt index 554f698389..f4e28a49ff 100644 --- a/doc/docgen.txt +++ b/doc/docgen.txt @@ -31,13 +31,13 @@ documentation with only their well-documented code. Example: .. code-block:: nim - type TPerson* = object + type Person* = object ## This type contains a description of a person name: string age: int Outputs:: - TPerson* = object + Person* = object name: string age: int @@ -268,8 +268,8 @@ The relationship of type to suffix is made by the proc ``complexName`` in the ``compiler/docgen.nim`` file. Here are some examples of complex names for symbols in the `system module `_. -* ``type TSignedInt = int | int8 | int16 | int32 | int64`` **=>** - `#TSignedInt `_ +* ``type SignedInt = int | int8 | int16 | int32 | int64`` **=>** + `#SignedInt `_ * ``var globalRaiseHook: proc (e: ref E_Base): bool {.nimcall.}`` **=>** `#globalRaiseHook `_ * ``const NimVersion = "0.0.0"`` **=>** @@ -307,7 +307,7 @@ columns is: Nim's rules (eg. \`^\` like in `the actors module `_). 2. Base filename plus anchor hyper link (eg. - ``algorithm.html#*,int,TSortOrder``). + ``algorithm.html#*,int,SortOrder``). 3. Optional human readable string to display as hyper link. If the value is not present or is the empty string, the hyper link will be rendered using the term. Prefix whitespace indicates that this entry is diff --git a/doc/filters.txt b/doc/filters.txt index 22df63490d..e725321e6e 100644 --- a/doc/filters.txt +++ b/doc/filters.txt @@ -173,7 +173,7 @@ The template engine is quite flexible. It is easy to produce a procedure that writes the template code directly to a file:: #! stdtmpl(emit="f.write") | standard - #proc writeHTMLPage(f: TFile, title, currentTab, content: string, + #proc writeHTMLPage(f: File, title, currentTab, content: string, # tabs: openArray[string]) = $title diff --git a/doc/idetools.txt b/doc/idetools.txt index e04f530f48..6a10e2a8cc 100644 --- a/doc/idetools.txt +++ b/doc/idetools.txt @@ -213,7 +213,7 @@ tab characters (``\t``). The values of each column are: ``proj.symbolName``. 4. Type/signature. For variables and enums this will contain the type of the symbol, for procs, methods and templates this will - contain the full unique signature (e.g. ``proc (TFile)``). + contain the full unique signature (e.g. ``proc (File)``). 5. Full path to the file containing the symbol. 6. Line where the symbol is located in the file. Lines start to count at **1**. @@ -258,8 +258,8 @@ skEnumField .. code-block:: nim Open(filename, fmWrite) - --> col 2: system.TFileMode.fmWrite - col 3: TFileMode + --> col 2: system.FileMode.fmWrite + col 3: FileMode col 7: "" @@ -296,7 +296,7 @@ posterior instances of the iterator. text = "some text" letters = toSeq(runes(text)) --> col 2: unicode.runes - col 3: iterator (string): TRune + col 3: iterator (string): Rune col 7: "iterates over any unicode character of the string `s`." @@ -423,7 +423,7 @@ returned by idetools returns also the pragmas for the proc. .. code-block:: nim Open(filename, fmWrite) --> col 2: system.Open - col 3: proc (var TFile, string, TFileMode, int): bool + col 3: proc (var File, string, FileMode, int): bool col 7: "Opens a file named `filename` with given `mode`. @@ -487,9 +487,9 @@ skType .. code-block:: nim proc writeTempFile() = - var output: TFile - --> col 2: system.TFile - col 3: TFile + var output: File + --> col 2: system.File + col 3: File col 7: "" @@ -502,11 +502,11 @@ skVar .. code-block:: nim proc writeTempFile() = - var output: TFile + var output: File output.open("/tmp/somefile", fmWrite) output.write("test") --> col 2: $MODULE.writeTempFile.output - col 3: TFile + col 3: File col 7: "" diff --git a/doc/nimc.txt b/doc/nimc.txt index a2274febd2..7aa7afb3af 100644 --- a/doc/nimc.txt +++ b/doc/nimc.txt @@ -311,8 +311,8 @@ underlying C ``struct`` in a ``sizeof`` expression: .. code-block:: Nim type - TDIR* {.importc: "DIR", header: "", - final, pure, incompleteStruct.} = object + DIR* {.importc: "DIR", header: "", + final, pure, incompleteStruct.} = object Compile pragma @@ -418,8 +418,8 @@ interfacing with libraries written in C++: irr = "" type - TIrrlichtDevice {.final, header: irr, importc: "IrrlichtDevice".} = object - PIrrlichtDevice = ptr TIrrlichtDevice + IrrlichtDeviceObj {.final, header: irr, importc: "IrrlichtDevice".} = object + IrrlichtDevice = ptr IrrlichtDeviceObj proc createDevice(): PIrrlichtDevice {. header: irr, importc: "createDevice".} @@ -465,11 +465,11 @@ allows *sloppy* interfacing with libraries written in Objective C: """.} type - TId {.importc: "id", header: "", final.} = distinct int + Id {.importc: "id", header: "", final.} = distinct int - proc newGreeter: TId {.importobjc: "Greeter new", nodecl.} - proc greet(self: TId, x, y: int) {.importobjc: "greet", nodecl.} - proc free(self: TId) {.importobjc: "free", nodecl.} + proc newGreeter: Id {.importobjc: "Greeter new", nodecl.} + proc greet(self: Id, x, y: int) {.importobjc: "greet", nodecl.} + proc free(self: Id) {.importobjc: "free", nodecl.} var g = newGreeter() g.greet(12, 34) diff --git a/doc/pegdocs.txt b/doc/pegdocs.txt index d22d81a5ae..118949cad4 100644 --- a/doc/pegdocs.txt +++ b/doc/pegdocs.txt @@ -213,7 +213,7 @@ example ``*`` should not be greedy, so ``\[.*?\]`` should be used instead. PEG construction ---------------- There are two ways to construct a PEG in Nim code: -(1) Parsing a string into an AST which consists of `TPeg` nodes with the +(1) Parsing a string into an AST which consists of `Peg` nodes with the `peg` proc. (2) Constructing the AST directly with proc calls. This method does not support constructing rules, only simple expressions and is not as diff --git a/doc/sets_fragment.txt b/doc/sets_fragment.txt index 59d4348075..84b13e6724 100644 --- a/doc/sets_fragment.txt +++ b/doc/sets_fragment.txt @@ -8,9 +8,9 @@ can also be used to include elements (and ranges of elements): .. code-block:: nim type - TCharSet = set[char] + CharSet = set[char] var - x: TCharSet + x: CharSet x = {'a'..'z', '0'..'9'} # This constructs a set that contains the # letters from 'a' to 'z' and the digits # from '0' to '9' diff --git a/doc/tut1.txt b/doc/tut1.txt index 4e419d19f9..b2991ba809 100644 --- a/doc/tut1.txt +++ b/doc/tut1.txt @@ -1350,11 +1350,11 @@ integer. .. code-block:: nim type - TPerson = tuple[name: string, age: int] # type representing a person: - # a person consists of a name - # and an age + Person = tuple[name: string, age: int] # type representing a person: + # a person consists of a name + # and an age var - person: TPerson + person: Person person = (name: "Peter", age: 30) # the same, but less readable: person = ("Peter", 30) @@ -1373,7 +1373,7 @@ integer. # The following line does not compile, they are different tuples! #person = building # --> Error: type mismatch: got (tuple[street: string, number: int]) - # but expected 'TPerson' + # but expected 'Person' # The following works because the field names and types are the same. var teacher: tuple[name: string, age: int] = ("Mark", 42) diff --git a/doc/tut2.txt b/doc/tut2.txt index b9fff93b9e..dbf50894bd 100644 --- a/doc/tut2.txt +++ b/doc/tut2.txt @@ -56,19 +56,19 @@ Objects have access to their type at runtime. There is an .. code-block:: nim type - TPerson = object of RootObj + Person = object of RootObj name*: string # the * means that `name` is accessible from other modules age: int # no * means that the field is hidden from other modules - TStudent = object of TPerson # TStudent inherits from TPerson - id: int # with an id field + Student = object of Person # Student inherits from Person + id: int # with an id field var - student: TStudent - person: TPerson - assert(student of TStudent) # is true + student: Student + person: Person + assert(student of Student) # is true # object construction: - student = TStudent(name: "Anton", age: 5, id: 2) + student = Student(name: "Anton", age: 5, id: 2) Object fields that should be visible from outside the defining module have to be marked by ``*``. In contrast to tuples, different object types are @@ -100,15 +100,15 @@ Example: .. code-block:: nim type - PNode = ref TNode # a traced reference to a TNode - TNode = object - le, ri: PNode # left and right subtrees - sym: ref TSym # leaves contain a reference to a TSym + Node = ref NodeObj # a traced reference to a NodeObj + NodeObj = object + le, ri: Node # left and right subtrees + sym: ref Sym # leaves contain a reference to a Sym - TSym = object # a symbol - name: string # the symbol's name - line: int # the line the symbol was declared in - code: PNode # the symbol's abstract syntax tree + Sym = object # a symbol + name: string # the symbol's name + line: int # the line the symbol was declared in + code: PNode # the symbol's abstract syntax tree Type conversions @@ -126,11 +126,11 @@ The syntax for type conversions is ``destination_type(expression_to_convert)`` (like an ordinary call): .. code-block:: nim - proc getID(x: TPerson): int = - TStudent(x).id + proc getID(x: Person): int = + Student(x).id The ``InvalidObjectConversionError`` exception is raised if ``x`` is not a -``TStudent``. +``Student``. Object variants @@ -144,16 +144,16 @@ An example: # This is an example how an abstract syntax tree could be modeled in Nim type - TNodeKind = enum # the different node types + NodeKind = enum # the different node types nkInt, # a leaf with an integer value nkFloat, # a leaf with a float value nkString, # a leaf with a string value nkAdd, # an addition nkSub, # a subtraction nkIf # an if statement - PNode = ref TNode - TNode = object - case kind: TNodeKind # the ``kind`` field is the discriminator + Node = ref NodeObj + NodeObj = object + case kind: NodeKind # the ``kind`` field is the discriminator of nkInt: intVal: int of nkFloat: floatVal: float of nkString: strVal: string @@ -228,21 +228,21 @@ is needed: .. code-block:: nim type - TSocket* = object of RootObj + Socket* = object of RootObj FHost: int # cannot be accessed from the outside of the module # the `F` prefix is a convention to avoid clashes since # the accessors are named `host` - proc `host=`*(s: var TSocket, value: int) {.inline.} = + proc `host=`*(s: var Socket, value: int) {.inline.} = ## setter of hostAddr s.FHost = value - proc host*(s: TSocket): int {.inline.} = + proc host*(s: Socket): int {.inline.} = ## getter of hostAddr s.FHost var - s: TSocket + s: Socket s.host = 34 # same as `host=`(s, 34) (The example also shows ``inline`` procedures.) @@ -253,10 +253,10 @@ The ``[]`` array access operator can be overloaded to provide .. code-block:: nim type - TVector* = object + Vector* = object x, y, z: float - proc `[]=`* (v: var TVector, i: int, value: float) = + proc `[]=`* (v: var Vector, i: int, value: float) = # setter case i of 0: v.x = value @@ -264,7 +264,7 @@ The ``[]`` array access operator can be overloaded to provide of 2: v.z = value else: assert(false) - proc `[]`* (v: TVector, i: int): float = + proc `[]`* (v: Vector, i: int): float = # getter case i of 0: result = v.x @@ -313,27 +313,27 @@ dispatching: .. code-block:: nim type - TThing = object of RootObj - TUnit = object of TThing + Thing = object of RootObj + Unit = object of Thing x: int - method collide(a, b: TThing) {.inline.} = + method collide(a, b: Thing) {.inline.} = quit "to override!" - method collide(a: TThing, b: TUnit) {.inline.} = + method collide(a: Thing, b: Unit) {.inline.} = echo "1" - method collide(a: TUnit, b: TThing) {.inline.} = + method collide(a: Unit, b: Thing) {.inline.} = echo "2" var - a, b: TUnit + a, b: Unit collide(a, b) # output: 2 As the example demonstrates, invocation of a multi-method cannot be ambiguous: Collide 2 is preferred over collide 1 because the resolution works from left to -right. Thus ``TUnit, TThing`` is preferred over ``TThing, TUnit``. +right. Thus ``Unit, Thing`` is preferred over ``Thing, Unit``. **Perfomance note**: Nim does not produce a virtual method table, but generates dispatch trees. This avoids the expensive indirect branch for method @@ -479,18 +479,18 @@ containers: .. code-block:: nim type - TBinaryTree[T] = object # TBinaryTree is a generic type with - # with generic param ``T`` - le, ri: ref TBinaryTree[T] # left and right subtrees; may be nil - data: T # the data stored in a node - PBinaryTree*[T] = ref TBinaryTree[T] # type that is exported + BinaryTreeObj[T] = object # BinaryTree is a generic type with + # with generic param ``T`` + le, ri: BinaryTree[T] # left and right subtrees; may be nil + data: T # the data stored in a node + BinaryTree*[T] = ref BinaryTreeObj[T] # type that is exported - proc newNode*[T](data: T): PBinaryTree[T] = + proc newNode*[T](data: T): BinaryTree[T] = # constructor for a node new(result) result.data = data - proc add*[T](root: var PBinaryTree[T], n: PBinaryTree[T]) = + proc add*[T](root: var BinaryTree[T], n: BinaryTree[T]) = # insert a node into the tree if root == nil: root = n @@ -511,15 +511,15 @@ containers: return it = it.ri - proc add*[T](root: var PBinaryTree[T], data: T) = + proc add*[T](root: var BinaryTree[T], data: T) = # convenience proc: add(root, newNode(data)) - iterator preorder*[T](root: PBinaryTree[T]): T = + iterator preorder*[T](root: BinaryTree[T]): T = # Preorder traversal of a binary tree. # Since recursive iterators are not yet implemented, # this uses an explicit stack (which is more efficient anyway): - var stack: seq[PBinaryTree[T]] = @[root] + var stack: seq[BinaryTree[T]] = @[root] while stack.len > 0: var n = stack.pop() while n != nil: @@ -528,7 +528,7 @@ containers: n = n.le # and follow the left pointer var - root: PBinaryTree[string] # instantiate a PBinaryTree with ``string`` + root: BinaryTree[string] # instantiate a BinaryTree with ``string`` add(root, newNode("hello")) # instantiates ``newNode`` and ``add`` add(root, "world") # instantiates the second ``add`` proc for str in preorder(root): @@ -863,7 +863,7 @@ precisely made for compilation time (just like `gorge `_ which executes an external program and captures its output). The interesting thing is that our macro does not return a runtime `Table -`_ object. Instead, it builds up Nim source code into +`_ object. Instead, it builds up Nim source code into the ``source`` variable. For each line of the configuration file a ``const`` variable will be generated (line 15). To avoid conflicts we prefix these variables with ``cfg``. In essence, what the compiler is doing is replacing