diff options
Diffstat (limited to 'doc/manual.txt')
| -rw-r--r-- | doc/manual.txt | 114 |
1 files changed, 59 insertions, 55 deletions
diff --git a/doc/manual.txt b/doc/manual.txt index 16e025ee0..fb357f7d3 100644 --- a/doc/manual.txt +++ b/doc/manual.txt @@ -1701,11 +1701,11 @@ algorithm returns true: result = isOrdinal(t) or t.kind in {float, float32, float64} proc isExplicitlyConvertible(a, b: PType): bool = + result = false if isImplicitlyConvertible(a, b): return true if typeEqualsOrDistinct(a, b): return true if isIntegralType(a) and isIntegralType(b): return true if isSubtype(a, b) or isSubtype(b, a): return true - return false The convertible relation can be relaxed by a user-defined type `converter`:idx:. @@ -1774,7 +1774,7 @@ Example: .. code-block:: nimrod proc p(x, y: int): int = - return x + y + result = x + y discard p(3, 4) # discard the return value of `p` @@ -1789,7 +1789,7 @@ been declared with the `discardable`:idx: pragma: .. code-block:: nimrod proc p(x, y: int): int {.discardable.} = - return x + y + result = x + y p(3, 4) # now valid @@ -2440,7 +2440,7 @@ A procedure cannot modify its parameters (unless the parameters have the type .. code-block:: nimrod proc `$` (x: int): string = # converts an integer to a string; this is a prefix operator. - return intToStr(x) + result = intToStr(x) Operators with one parameter are prefix operators, operators with two parameters are infix operators. (However, the parser distinguishes these from @@ -2454,7 +2454,7 @@ notation. (Thus an operator can have more than two parameters): .. code-block:: nimrod proc `*+` (a, b, c: int): int = # Multiply and add - return a * b + c + result = a * b + c assert `*+`(3, 4, 6) == `*`(a, `+`(b, c)) @@ -2500,7 +2500,7 @@ different; for this a special setter syntax is needed: proc host*(s: TSocket): int {.inline.} = ## getter of hostAddr - return s.FHost + s.FHost var s: TSocket @@ -2650,11 +2650,12 @@ return values. This can be done in a cleaner way by returning a tuple: .. code-block:: nimrod proc divmod(a, b: int): tuple[res, remainder: int] = - return (a div b, a mod b) + (a div b, a mod b) var t = divmod(8, 5) + assert t.res == 1 - assert t.remainder = 3 + assert t.remainder == 3 One can use `tuple unpacking`:idx: to access the tuple's fields: @@ -2726,7 +2727,7 @@ dispatch. method eval(e: ref TPlusExpr): int = # watch out: relies on dynamic binding - return eval(e.a) + eval(e.b) + result = eval(e.a) + eval(e.b) proc newLit(x: int): ref TLiteral = new(result) @@ -2925,7 +2926,7 @@ parameters of an outer factory proc: .. code-block:: nimrod proc mycount(a, b: int): iterator (): int = - return iterator (): int = + result = iterator (): int = var x = a while x <= b: yield x @@ -3375,9 +3376,9 @@ module to illustrate this: ## requires `x` and `y` to be of the same tuple type ## generic ``==`` operator for tuples that is lifted from the components ## of `x` and `y`. + result = true for a, b in fields(x, y): - if a != b: return false - return true + if a != b: result = false Alternatively, the ``distinct`` type modifier can be applied to the type class to allow each param matching the type class to bind to a different type. @@ -3999,9 +4000,9 @@ predicate: proc re(pattern: semistatic[string]): TRegEx = when isStatic(pattern): - return precompiledRegex(pattern) + result = precompiledRegex(pattern) else: - return compile(pattern) + result = compile(pattern) Static params can also appear in the signatures of generic types: @@ -4508,7 +4509,7 @@ This is best illustrated by an example: proc p*(x: A.T1): A.T1 = # this works because the compiler has already # added T1 to A's interface symbol table - return x + 1 + result = x + 1 Import statement @@ -5136,51 +5137,54 @@ Example: .. code-block:: nimrod {.deadCodeElim: on.} -NoForward pragma ----------------- -The `noforward`:idx: pragma can be used to turn on and off a special compilation -mode that to large extent eliminates the need for forward declarations. In this -mode, the proc definitions may appear out of order and the compiler will postpone -their semantic analysis and compilation until it actually needs to generate code -using the definitions. In this regard, this mode is similar to the modus operandi -of dynamic scripting languages, where the function calls are not resolved until -the code is executed. Here is the detailed algorithm taken by the compiler: - -1. When a callable symbol is first encountered, the compiler will only note the -symbol callable name and it will add it to the appropriate overload set in the -current scope. At this step, it won't try to resolve any of the type expressions -used in the signature of the symbol (so they can refer to other not yet defined -symbols). - -2. When a top level call is encountered (usually at the very end of the module), -the compiler will try to determine the actual types of all of the symbols in the -matching overload set. This is a potentially recursive process as the signatures -of the symbols may include other call expressions, whoose types will be resolved -at this point too. - -3. Finally, after the best overload is picked, the compiler will start compiling -the body of the respective symbol. This in turn will lead the compiler to discover -more call expresions that need to be resolved and steps 2 and 3 will be repeated -as necessary. - -Please note that if a callable symbol is never used in this scenario, its body -will never be compiled. This is the default behavior leading to best compilation -times, but if exhaustive compilation of all definitions is required, using -``nimrod check`` provides this option as well. -Example: +.. + NoForward pragma + ---------------- + The `noforward`:idx: pragma can be used to turn on and off a special compilation + mode that to large extent eliminates the need for forward declarations. In this + mode, the proc definitions may appear out of order and the compiler will postpone + their semantic analysis and compilation until it actually needs to generate code + using the definitions. In this regard, this mode is similar to the modus operandi + of dynamic scripting languages, where the function calls are not resolved until + the code is executed. Here is the detailed algorithm taken by the compiler: -.. code-block:: nimrod + 1. When a callable symbol is first encountered, the compiler will only note the + symbol callable name and it will add it to the appropriate overload set in the + current scope. At this step, it won't try to resolve any of the type expressions + used in the signature of the symbol (so they can refer to other not yet defined + symbols). + + 2. When a top level call is encountered (usually at the very end of the module), + the compiler will try to determine the actual types of all of the symbols in the + matching overload set. This is a potentially recursive process as the signatures + of the symbols may include other call expressions, whoose types will be resolved + at this point too. + + 3. Finally, after the best overload is picked, the compiler will start compiling + the body of the respective symbol. This in turn will lead the compiler to discover + more call expresions that need to be resolved and steps 2 and 3 will be repeated + as necessary. + + Please note that if a callable symbol is never used in this scenario, its body + will never be compiled. This is the default behavior leading to best compilation + times, but if exhaustive compilation of all definitions is required, using + ``nimrod check`` provides this option as well. + + Example: + + .. code-block:: nimrod + + {.noforward: on.} - {.noforward: on.} + proc foo(x: int) = + bar x - proc foo(x: int) = - bar x + proc bar(x: int) = + echo x - proc bar(x: int) = - echo x + foo(10) - foo(10) Pragma pragma ------------- @@ -5199,7 +5203,7 @@ Example: {.pragma: rtl, importc, dynlib: "client.dll", cdecl.} proc p*(a, b: int): int {.rtl.} = - return a+b + result = a+b In the example a new pragma named ``rtl`` is introduced that either imports a symbol from a dynamic library or exports the symbol for dynamic library |