mirrors/Nim
1
0
Fork 0
mirror of https://github.com/nim-lang/Nim.git synced 2025-12-28 17:04:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix a couple of typos, grammar, and removal of whitespace

Browse Source
This commit is contained in:
Joseph Poirier
2015-01-03 14:24:02 -06:00
parent 10ba9c4dc1
commit cd73b3b12b
3 changed files with 103 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

130
doc/manual/types.txt
View File

@@ -40,7 +40,7 @@ These integer types are pre-defined:
``int``
the generic signed integer type; its size is platform dependent and has the
same size as a pointer. This type should be used in general. An integer
same size as a pointer. This type should be used in general. An integer
literal that has no type suffix is of this type.
intXX
@@ -51,7 +51,7 @@ intXX
``uint``
the generic `unsigned integer`:idx: type; its size is platform dependent and
has the same size as a pointer. An integer literal with the type
has the same size as a pointer. An integer literal with the type
suffix ``'u`` is of this type.
uintXX
@@ -59,15 +59,15 @@ uintXX
(example: uint16 is a 16 bit wide unsigned integer).
The current implementation supports ``uint8``, ``uint16``, ``uint32``,
``uint64``. Literals of these types have the suffix 'uXX.
Unsigned operations all wrap around; they cannot lead to over- or
Unsigned operations all wrap around; they cannot lead to over- or
underflow errors.
In addition to the usual arithmetic operators for signed and unsigned integers
(``+ - *`` etc.) there are also operators that formally work on *signed*
integers but treat their arguments as *unsigned*: They are mostly provided
for backwards compatibility with older versions of the language that lacked
unsigned integer types. These unsigned operations for signed integers use
(``+ - *`` etc.) there are also operators that formally work on *signed*
integers but treat their arguments as *unsigned*: They are mostly provided
for backwards compatibility with older versions of the language that lacked
unsigned integer types. These unsigned operations for signed integers use
the ``%`` suffix as convention:
@@ -98,7 +98,7 @@ operation meaning
kinds of integer types are used: the smaller type is converted to the larger.
A `narrowing type conversion`:idx: converts a larger to a smaller type (for
example ``int32 -> int16``. A `widening type conversion`:idx: converts a
example ``int32 -> int16``. A `widening type conversion`:idx: converts a
smaller type to a larger type (for example ``int16 -> int32``). In Nim only
widening type conversions are *implicit*:
@@ -111,7 +111,7 @@ widening type conversions are *implicit*:
However, ``int`` literals are implicitly convertible to a smaller integer type
if the literal's value fits this smaller type and such a conversion is less
expensive than other implicit conversions, so ``myInt16 + 34`` produces
expensive than other implicit conversions, so ``myInt16 + 34`` produces
an ``int16`` result.
For further details, see `Convertible relation`_.
@@ -137,12 +137,12 @@ determined). Assignments from the base type to one of its subrange types
A subrange type has the same size as its base type (``int`` in the example).
Nim requires `interval arithmetic`:idx: for subrange types over a set
of built-in operators that involve constants: ``x %% 3`` is of
type ``range[0..2]``. The following built-in operators for integers are
of built-in operators that involve constants: ``x %% 3`` is of
type ``range[0..2]``. The following built-in operators for integers are
affected by this rule: ``-``, ``+``, ``*``, ``min``, ``max``, ``succ``,
``pred``, ``mod``, ``div``, ``%%``, ``and`` (bitwise ``and``).
Bitwise ``and`` only produces a ``range`` if one of its operands is a
Bitwise ``and`` only produces a ``range`` if one of its operands is a
constant *x* so that (x+1) is a number of two.
(Bitwise ``and`` is then a ``%%`` operation.)
@@ -155,7 +155,7 @@ This means that the following code is accepted:
of 9: echo "C"
of 10: echo "D"
# note: no ``else`` required as (x and 3) + 7 has the type: range[7..10]
Pre-defined floating point types
--------------------------------
@@ -186,17 +186,17 @@ The IEEE standard defines five types of floating-point exceptions:
for example 0.0/0.0, sqrt(-1.0), and log(-37.8).
* Division by zero: divisor is zero and dividend is a finite nonzero number,
for example 1.0/0.0.
* Overflow: operation produces a result that exceeds the range of the exponent,
* Overflow: operation produces a result that exceeds the range of the exponent,
for example MAXDOUBLE+0.0000000000001e308.
* Underflow: operation produces a result that is too small to be represented
* Underflow: operation produces a result that is too small to be represented
as a normal number, for example, MINDOUBLE * MINDOUBLE.
* Inexact: operation produces a result that cannot be represented with infinite
* Inexact: operation produces a result that cannot be represented with infinite
precision, for example, 2.0 / 3.0, log(1.1) and 0.1 in input.
The IEEE exceptions are either ignored at runtime or mapped to the
The IEEE exceptions are either ignored at runtime or mapped to the
Nim exceptions: `FloatInvalidOpError`:idx:, `FloatDivByZeroError`:idx:,
`FloatOverflowError`:idx:, `FloatUnderflowError`:idx:,
and `FloatInexactError`:idx:.
and `FloatInexactError`:idx:.
These exceptions inherit from the `FloatingPointError`:idx: base class.
Nim provides the pragmas `NaNChecks`:idx: and `InfChecks`:idx: to control
@@ -212,7 +212,7 @@ whether the IEEE exceptions are ignored or trap a Nim exception:
In the current implementation ``FloatDivByZeroError`` and ``FloatInexactError``
are never raised. ``FloatOverflowError`` is raised instead of
``FloatDivByZeroError``.
There is also a `floatChecks`:idx: pragma that is a short-cut for the
There is also a `floatChecks`:idx: pragma that is a short-cut for the
combination of ``NaNChecks`` and ``InfChecks`` pragmas. ``floatChecks`` are
turned off as default.
@@ -303,7 +303,7 @@ and ``pred`` are not available for them either.
The compiler supports the built-in stringify operator ``$`` for enumerations.
The stringify's result can be controlled by explicitly giving the string
The stringify's result can be controlled by explicitly giving the string
values to use:
.. code-block:: nim
@@ -315,12 +315,12 @@ values to use:
valueC = 2,
valueD = (3, "abc")
As can be seen from the example, it is possible to both specify a field's
As can be seen from the example, it is possible to both specify a field's
ordinal value and its string value by using a tuple. It is also
possible to only specify one of them.
An enum can be marked with the ``pure`` pragma so that it's fields are not
added to the current scope, so they always need to be accessed
added to the current scope, so they always need to be accessed
via ``MyEnum.value``:
.. code-block:: nim
@@ -328,7 +328,7 @@ via ``MyEnum.value``:
type
MyEnum {.pure.} = enum
valueA, valueB, valueC, valueD
echo valueA # error: Unknown identifier
echo MyEnum.valueA # works
@@ -364,22 +364,22 @@ cstring type
------------
The ``cstring`` type represents a pointer to a zero-terminated char array
compatible to the type ``char*`` in Ansi C. Its primary purpose lies in easy
interfacing with C. The index operation ``s[i]`` means the i-th *char* of
interfacing with C. The index operation ``s[i]`` means the i-th *char* of
``s``; however no bounds checking for ``cstring`` is performed making the
index operation unsafe.
A Nim ``string`` is implicitly convertible
A Nim ``string`` is implicitly convertible
to ``cstring`` for convenience. If a Nim string is passed to a C-style
variadic proc, it is implicitly converted to ``cstring`` too:
.. code-block:: nim
proc printf(formatstr: cstring) {.importc: "printf", varargs,
proc printf(formatstr: cstring) {.importc: "printf", varargs,
header: "<stdio.h>".}
printf("This works %s", "as expected")
Even though the conversion is implicit, it is not *safe*: The garbage collector
does not consider a ``cstring`` to be a root and may collect the underlying
does not consider a ``cstring`` to be a root and may collect the underlying
memory. However in practice this almost never happens as the GC considers
stack roots conservatively. One can use the builtin procs ``GC_ref`` and
``GC_unref`` to keep the string data alive for the rare cases where it does
@@ -390,7 +390,7 @@ string from a cstring:
.. code-block:: nim
var str: string = "Hello!"
var cstr: cstring = s
var cstr: cstring = str
var newstr: string = $cstr
@@ -410,9 +410,9 @@ integers from 0 to ``len(A)-1``. An array expression may be constructed by the
array constructor ``[]``.
Sequences are similar to arrays but of dynamic length which may change
during runtime (like strings). Sequences are implemented as growable arrays,
during runtime (like strings). Sequences are implemented as growable arrays,
allocating pieces of memory as items are added. A sequence ``S`` is always
indexed by integers from 0 to ``len(S)-1`` and its bounds are checked.
indexed by integers from 0 to ``len(S)-1`` and its bounds are checked.
Sequences can be constructed by the array constructor ``[]`` in conjunction
with the array to sequence operator ``@``. Another way to allocate space for a
sequence is to call the built-in ``newSeq`` procedure.
@@ -452,11 +452,11 @@ Open arrays
Often fixed size arrays turn out to be too inflexible; procedures should
be able to deal with arrays of different sizes. The `openarray`:idx: type
allows this; it can only be used for parameters. Openarrays are always
indexed with an ``int`` starting at position 0. The ``len``, ``low``
and ``high`` operations are available for open arrays too. Any array with
a compatible base type can be passed to an openarray parameter, the index
type does not matter. In addition to arrays sequences can also be passed
allows this; it can only be used for parameters. Openarrays are always
indexed with an ``int`` starting at position 0. The ``len``, ``low``
and ``high`` operations are available for open arrays too. Any array with
a compatible base type can be passed to an openarray parameter, the index
type does not matter. In addition to arrays sequences can also be passed
to an open array parameter.
The openarray type cannot be nested: multidimensional openarrays are not
@@ -467,7 +467,7 @@ Varargs
-------
A ``varargs`` parameter is an openarray parameter that additionally
allows to pass a variable number of arguments to a procedure. The compiler
allows to pass a variable number of arguments to a procedure. The compiler
converts the list of arguments to an array implicitly:
.. code-block:: nim
@@ -494,7 +494,7 @@ type conversions in this context:
# is transformed to:
myWriteln(stdout, [$123, $"def", $4.0])
In this example ``$`` is applied to any argument that is passed to the
In this example ``$`` is applied to any argument that is passed to the
parameter ``a``. (Note that ``$`` applied to strings is a nop.)
@@ -531,7 +531,7 @@ in future versions of the compiler.
person = (creditCard: "Peter", id: 20)
The implementation aligns the fields for best access performance. The alignment
is compatible with the way the C compiler does it.
is compatible with the way the C compiler does it.
For consistency with ``object`` declarations, tuples in a ``type`` section
can also be defined with indentation instead of ``[]``:
@@ -571,7 +571,7 @@ Object construction
-------------------
Objects can also be created with an `object construction expression`:idx: that
has the syntax ``T(fieldA: valueA, fieldB: valueB, ...)`` where ``T`` is
has the syntax ``T(fieldA: valueA, fieldB: valueB, ...)`` where ``T`` is
an ``object`` type or a ``ref object`` type:
.. code-block:: nim
@@ -617,10 +617,10 @@ An example:
# the following statement raises an `EInvalidField` exception, because
# n.kind's value does not fit and the ``nkString`` branch is not active:
n.strVal = ""
# invalid: would change the active object branch:
n.kind = nkInt
var x = PNode(kind: nkAdd, leftOp: PNode(kind: nkInt, intVal: 4),
rightOp: PNode(kind: nkInt, intVal: 2))
# valid: does not change the active object branch:
@@ -660,8 +660,8 @@ untraced references are *unsafe*. However for certain low-level operations
Traced references are declared with the **ref** keyword, untraced references
are declared with the **ptr** keyword.
An empty subscript ``[]`` notation can be used to derefer a reference,
the ``addr`` procedure returns the address of an item. An address is always
An empty subscript ``[]`` notation can be used to derefer a reference,
the ``addr`` procedure returns the address of an item. An address is always
an untraced reference.
Thus the usage of ``addr`` is an *unsafe* feature.
@@ -680,7 +680,7 @@ dereferencing operations for reference types:
var
n: PNode
new(n)
n.data = 9
n.data = 9
# no need to write n[].data; in fact n[].data is highly discouraged!
In order to simplify structural type checking, recursive tuples are not valid:
@@ -751,20 +751,20 @@ details like this when mixing garbage collected data with unmanaged memory.
Not nil annotation
------------------
All types for that ``nil`` is a valid value can be annotated to
All types for that ``nil`` is a valid value can be annotated to
exclude ``nil`` as a valid value with the ``not nil`` annotation:
.. code-block:: nim
type
PObject = ref TObj not nil
TProc = (proc (x, y: int)) not nil
proc p(x: PObject) =
echo "not nil"
# compiler catches this:
p(nil)
# and also this:
var x: PObject
p(x)
@@ -851,22 +851,22 @@ Examples:
forEach(printItem) # this will NOT compile because calling conventions differ
.. code-block:: nim
type
TOnMouseMove = proc (x, y: int) {.closure.}
proc onMouseMove(mouseX, mouseY: int) =
# has default calling convention
echo "x: ", mouseX, " y: ", mouseY
proc setOnMouseMove(mouseMoveEvent: TOnMouseMove) = discard
# ok, 'onMouseMove' has the default calling convention, which is compatible
# to 'closure':
setOnMouseMove(onMouseMove)
A subtle issue with procedural types is that the calling convention of the
procedure influences the type compatibility: procedural types are only
@@ -932,7 +932,7 @@ of the following conditions hold:
3) The procedure has a calling convention that differs from ``nimcall``.
4) The procedure is anonymous.
The rules' purpose is to prevent the case that extending a non-``procvar``
The rules' purpose is to prevent the case that extending a non-``procvar``
procedure with default parameters breaks client code.
The default calling convention is ``nimcall``, unless it is an inner proc (a
@@ -964,7 +964,7 @@ types are a perfect tool to model different currencies:
type
TDollar = distinct int
TEuro = distinct int
var
d: TDollar
e: TEuro
@@ -989,7 +989,7 @@ number without unit; and the same holds for division:
proc `*` (x: int, y: TDollar): TDollar =
result = TDollar(x * int(y))
proc `div` ...
This quickly gets tedious. The implementations are trivial and the compiler
@@ -1014,7 +1014,7 @@ currency. This can be solved with templates_.
template additive(typ: typedesc): stmt =
proc `+` *(x, y: typ): typ {.borrow.}
proc `-` *(x, y: typ): typ {.borrow.}
# unary operators:
proc `+` *(x: typ): typ {.borrow.}
proc `-` *(x: typ): typ {.borrow.}
@@ -1036,7 +1036,7 @@ currency. This can be solved with templates_.
additive(typ)
multiplicative(typ, base)
comparable(typ)
defineCurrency(TDollar, int)
defineCurrency(TEuro, int)
@@ -1127,21 +1127,21 @@ modules like `db_sqlite <db_sqlite.html>`_.
Void type
---------
The ``void`` type denotes the absense of any type. Parameters of
The ``void`` type denotes the absense of any type. Parameters of
type ``void`` are treated as non-existent, ``void`` as a return type means that
the procedure does not return a value:
.. code-block:: nim
proc nothing(x, y: void): void =
echo "ha"
nothing() # writes "ha" to stdout
The ``void`` type is particularly useful for generic code:
.. code-block:: nim
proc callProc[T](p: proc (x: T), x: T) =
when T is void:
when T is void:
p()
else:
p(x)
@@ -1151,13 +1151,13 @@ The ``void`` type is particularly useful for generic code:
callProc[int](intProc, 12)
callProc[void](emptyProc)
However, a ``void`` type cannot be inferred in generic code:
.. code-block:: nim
callProc(emptyProc)
callProc(emptyProc)
# Error: type mismatch: got (proc ())
# but expected one of:
# but expected one of:
# callProc(p: proc (T), x: T)
The ``void`` type is only valid for parameters and return types; other symbols

42
doc/tut2.txt
View File

@@ -35,7 +35,7 @@ Object Oriented Programming
===========================
While Nim's support for object oriented programming (OOP) is minimalistic,
powerful OOP technics can be used. OOP is seen as *one* way to design a
powerful OOP techniques can be used. OOP is seen as *one* way to design a
program, not *the only* way. Often a procedural approach leads to simpler
and more efficient code. In particular, prefering composition over inheritance
is often the better design.
@@ -77,8 +77,8 @@ section.
Inheritance is done with the ``object of`` syntax. Multiple inheritance is
currently not supported. If an object type has no suitable ancestor, ``RootObj``
can be used as its ancestor, but this is only a convention. Objects that have
no ancestor are implicitly ``final``. You can use the ``inheritable`` pragma
can be used as its ancestor, but this is only a convention. Objects that have
no ancestor are implicitly ``final``. You can use the ``inheritable`` pragma
to introduce new object roots apart from ``system.RootObj``. (This is used
in the GTK wrapper for instance.)
@@ -199,7 +199,7 @@ This method call syntax is not restricted to objects, it can be used
for any type:
.. code-block:: nim
echo("abc".len) # is the same as echo(len("abc"))
echo("abc".toUpper())
echo({'a', 'b', 'c'}.card)
@@ -212,7 +212,7 @@ So "pure object oriented" code is easy to write:
.. code-block:: nim
import strutils
stdout.writeln("Give a list of numbers (separated by spaces): ")
stdout.write(stdin.readLine.split.map(parseInt).max.`$`)
stdout.writeln(" is the maximum!")
@@ -226,7 +226,7 @@ the same. But setting a value is different; for this a special setter syntax
is needed:
.. code-block:: nim
type
TSocket* = object of RootObj
FHost: int # cannot be accessed from the outside of the module
@@ -236,7 +236,7 @@ is needed:
proc `host=`*(s: var TSocket, value: int) {.inline.} =
## setter of hostAddr
s.FHost = value
proc host*(s: TSocket): int {.inline.} =
## getter of hostAddr
s.FHost
@@ -294,15 +294,15 @@ Procedures always use static dispatch. For dynamic dispatch replace the
method eval(e: PExpr): int =
# override this base method
quit "to override!"
method eval(e: PLiteral): int = e.x
method eval(e: PPlusExpr): int = eval(e.a) + eval(e.b)
proc newLit(x: int): PLiteral = PLiteral(x: x)
proc newPlus(a, b: PExpr): PPlusExpr = PPlusExpr(a: a, b: b)
echo eval(newPlus(newPlus(newLit(1), newLit(2)), newLit(4)))
Note that in the example the constructors ``newLit`` and ``newPlus`` are procs
because they should use static binding, but ``eval`` is a method because it
requires dynamic binding.
@@ -316,16 +316,16 @@ dispatching:
TThing = object of RootObj
TUnit = object of TThing
x: int
method collide(a, b: TThing) {.inline.} =
quit "to override!"
method collide(a: TThing, b: TUnit) {.inline.} =
echo "1"
method collide(a: TUnit, b: TThing) {.inline.} =
echo "2"
var
a, b: TUnit
collide(a, b) # output: 2
@@ -526,7 +526,7 @@ containers:
yield n.data
add(stack, n.ri) # push right subtree onto the stack
n = n.le # and follow the left pointer
var
root: PBinaryTree[string] # instantiate a PBinaryTree with ``string``
add(root, newNode("hello")) # instantiates ``newNode`` and ``add``
@@ -578,7 +578,7 @@ simple proc for logging:
proc log(msg: string) {.inline.} =
if debug: stdout.writeln(msg)
var
x = 4
log("x has the value: " & $x)
@@ -595,7 +595,7 @@ Turning the ``log`` proc into a template solves this problem:
template log(msg: string) =
if debug: stdout.writeln(msg)
var
x = 4
log("x has the value: " & $x)
@@ -622,11 +622,11 @@ via a special ``:`` syntax:
close(f)
else:
quit("cannot open: " & fn)
withFile(txt, "ttempl3.txt", fmWrite):
txt.writeln("line 1")
txt.writeln("line 2")
In the example the two ``writeln`` statements are bound to the ``body``
parameter. The ``withFile`` template contains boilerplate code and helps to
avoid a common bug: to forget to close the file. Note how the
@@ -739,7 +739,7 @@ Term rewriting macros
---------------------
Term rewriting macros can be used to enhance the compilation process
with user defined optimizations; see this `document <trmacros.html>`_ for
with user defined optimizations; see this `document <trmacros.html>`_ for
further information.

34
web/index.txt
View File

@@ -5,16 +5,16 @@ Home
Welcome to Nim
--------------
**Nim** (formerly known as "Nimrod") is a statically typed, imperative
programming language that tries to give the programmer ultimate power without
**Nim** (formerly known as "Nimrod") is a statically typed, imperative
programming language that tries to give the programmer ultimate power without
compromises on runtime efficiency. This means it focuses on compile-time
mechanisms in all their various forms.
Beneath a nice infix/indentation based syntax with a
powerful (AST based, hygienic) macro system lies a semantic model that supports
a soft realtime GC on thread local heaps. Asynchronous message passing is used
between threads, so no "stop the world" mechanism is necessary. An unsafe
shared memory heap is also provided for the increased efficiency that results
Beneath a nice infix/indentation based syntax with a
powerful (AST based, hygienic) macro system lies a semantic model that supports
a soft realtime GC on thread local heaps. Asynchronous message passing is used
between threads, so no "stop the world" mechanism is necessary. An unsafe
shared memory heap is also provided for the increased efficiency that results
from that model.
@@ -24,7 +24,7 @@ Nim is efficient
* Native code generation (currently via compilation to C), not dependent on a
virtual machine: **Nim produces small executables without dependencies
for easy redistribution.**
* A fast **non-tracing** garbage collector that supports soft
* A fast **non-tracing** garbage collector that supports soft
real-time systems (like games).
* System programming features: Ability to manage your own memory and access the
hardware directly. Pointers to garbage collected memory are distinguished
@@ -33,22 +33,22 @@ Nim is efficient
* Cross-module inlining.
* Dynamic method binding with inlining and without virtual method table.
* Compile time evaluation of user-defined functions.
* Whole program dead code elimination: Only *used functions* are included in
* Whole program dead code elimination: Only *used functions* are included in
the executable.
* Value-based datatypes: For instance, objects and arrays can be allocated on
* Value-based datatypes: For instance, objects and arrays can be allocated on
the stack.
Nim is expressive
=================
* **The Nim compiler and all of the standard library are implemented in
* **The Nim compiler and all of the standard libraries are implemented in
Nim.**
* Built-in high level datatypes: strings, sets, sequences, etc.
* Modern type system with local type inference, tuples, variants,
* Modern type system with local type inference, tuples, variants,
generics, etc.
* User-defineable operators; code with new operators is often easier to read
than code which overloads built-in operators. For example, a
than code which overloads built-in operators. For example, a
``=~`` operator is defined in the ``re`` module.
* Macros can modify the abstract syntax tree at compile time.
@@ -58,7 +58,7 @@ Nim is elegant
* Macros can use the imperative paradigm to construct parse trees. Nim
does not require a different coding style for meta programming.
* Macros cannot change Nim's syntax because there is no need for it.
* Macros cannot change Nim's syntax because there is no need for it.
Nim's syntax is flexible enough.
* Statements are grouped by indentation but can span multiple lines.
Indentation must not contain tabulators so the compiler always sees
@@ -72,12 +72,12 @@ Nim plays nice with others
Porting to other platforms is easy.
* **The Nim Compiler can also generate C++ or Objective C for easier
interfacing.**
* There are lots of bindings: for example, bindings to GTK2, the Windows API,
the POSIX API, OpenGL, SDL, Cairo, Python, Lua, TCL, X11, libzip, PCRE,
* There are lots of bindings: for example, bindings to GTK2, the Windows API,
the POSIX API, OpenGL, SDL, Cairo, Python, Lua, TCL, X11, libzip, PCRE,
libcurl, mySQL and SQLite are included in the standard distribution or
can easily be obtained via the
`Nimble package manager <https://github.com/nim-lang/nimble>`_.
* A C to Nim conversion utility: New bindings to C libraries are easily
* A C to Nim conversion utility: New bindings to C libraries are easily
generated by ``c2nim``.