Grammar and punctuation fixes

This commit is contained in:
Hugo Locurcio 2018-07-16 12:09:55 +02:00
parent 3b66a738c5
commit 6b3f5bd6eb
1 changed files with 23 additions and 24 deletions

View File

@ -1,6 +1,6 @@
****
**DISCLAIMER!**
**DISCLAIMER:**
Unofficial, work in progress!
There may be inaccuracies in this guide.
@ -41,18 +41,18 @@ Methods | No (Yes w/C++) | Yes
Multi-Methods | No | Yes
Exceptions | No (Yes w/C++) | Yes
\*Other backends supported and/or planned
\**See section below. Also: it's arguably possible to write OOP-style in pure C
\*Other backends supported and/or planned.
\**See section below. Also, it's arguably possible to write OOP-style in pure C.
### Philosophy
The key to understanding Nim is that Nim was designed to be as fast as C, but to be much safer. Many of the design-decisions are based on making it harder to shoot yourself in the foot. For example, in C you are required to use a pointer for most of your everyday programming needs. While Nim does give you pointers, Nim gives you other, safer tools for your everyday needs, while pointers are mostly reserved for interfacing with C and doing low-level system programming. In other words, C gives you a combined hammer and gun, while Nim gives you a separate gun and hammer.
The other important thing to know is that while C uses a separate language to do meta-programming (the preprocessor), Nim meta-programming is done with the Nim language itself. That means that most Nim code can be executed at compile time, and Nim's ability to generate Nim-code at compile time is much more sophisticated.
The other important thing to know is that while C uses a separate language to do meta-programming (the preprocessor), Nim meta-programming is done with the Nim language itself. That means that most Nim code can be executed at compile time, and Nim's ability to generate Nim code at compile time is much more sophisticated.
### Arrays
In C an array is more or less syntactic sugar for pointers. In Nim, arrays are much more strict and safe to use. They are pass-by-value (meaning they're copied at assignment). When passing an array to a proc in Nim, the argument is a read-only reference, meaning it can't be assigned to. Take the following example:
In C, an array is more or less syntactic sugar for pointers. In Nim, arrays are much more strict and safe to use. They are pass-by-value (meaning they're copied at assignment). When passing an array to a proc in Nim, the argument is a read-only reference, meaning it can't be assigned to. Take the following example:
**C:**
@ -81,46 +81,45 @@ var x = [1, 2, 3, 4]
foobar(x)
```
The C-code will compile, it may or may not crash. The Nim code will not compile. If you mean to change the array that was passed to the procedure, you can change the the signature of the procedure to ```proc foobar(z: var array[0..3, int])```. Now you will only get index out of bounds error. If you change the index in both lines to 1, the code will compile. If the index is a variable, Nim will include run-time checks on the bounds of the array.
The C code will compile; it may or may not crash. The Nim code will not compile. If you mean to change the array that was passed to the procedure, you can change the the signature of the procedure to ```proc foobar(z: var array[0..3, int])```. Now, you will only get index out of bounds error. If you change the index in both lines to 1, the code will compile. If the index is a variable, Nim will include run-time checks on the bounds of the array.
In C, you can pass an ``int[3]`` to the foobar function, and the compiler will not complain. In this case Nim would not compile. You can use an openarray to accept an array of any size, and you can use low(z) and high(z) to query the bounds of the array.
In C, you can pass an ``int[3]`` to the foobar function, and the compiler will not complain. In this case, Nim would not compile. You can use an openarray to accept an array of any size, and you can use low(z) and high(z) to query the bounds of the array.
Nim arrays can also be indexed from any number. That is, ``z: array[1..4, int]`` is an array of int indexed from 1 to 4. Trying to access ``z[0]`` would throw an index out bounds error.
Nim arrays can also be indexed from any number. That is, ``z: array[1..4, int]`` is an array of int indexed from 1 to 4. Trying to access ``z[0]`` would throw an "index out of bounds" error.
In C, there's nothing that stops you from keeping a pointer to a stack-allocated array after the function that declared it has returned (and the stack is invalidated). In Nim, this is true as well, but you are strongly discouraged from using pointers in Nim, and you can accomplish almost everything you'd otherwise use pointers for with normal arguments, "var" arguments, variables, and "ref".
### Unsigned integers
Nim strongly discourages the use of unsigned integers, as it's considered unnecessary and somewhat unsafe* for most applications.
Nim strongly discourages the use of unsigned integers, as it's considered unnecessary and [somewhat unsafe](http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/) for most applications.
*See: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
That said, unsigned integers are used and support for them has improved over the years. In most cases, you should only use them for systems programming use cases though, not for general applications if you can help it.
That said, unsigned integers are used and support for them has improved over the years. In most cases you should only use them for systems programming use cases though, not for general applications if you can help it.
### Object-orientation
### Object-Orientation
Objects in Nim have more features than structs in C, but behave quite differently from classes in C++. Objects support inheritance (not multiple inheritance). But otherwise most of the features that apply to objects simply apply to all types in Nim.
Objects in Nim have more features than structs in C, but behave quite differently from classes in C++. Objects support inheritance (but not multiple inheritance). Otherwise, most of the features that apply to objects simply apply to all types in Nim.
You can call a proc on objects with the ```anObject.foobar()```, but you can do that on any type (e.g. ints and arrays) as well. You can have methods on object, but you can have methods on any types, and for all the arguments, not just the first (in C++, implicit) one.
Nim does not have an implicit _this_/_self_.
Nim does not have an implicit `this` or `self`.
It is possible to implement object-orientation features from other languages (like C++, Java, etc. or Smalltalk, Obj-C, Ruby, etc.) through libraries, thanks to the extensive meta-programming features of Nim. These are at the moment mostly work-in-progress.
It is possible to implement object-orientation features from other languages (like C++, Java, etc. or Smalltalk, Objective-C, Ruby, etc.) through libraries, thanks to the extensive meta-programming features of Nim. These are at the moment mostly work-in-progress.
### Structs - Tuples and Objects
Tuples and Objects in Nim are kind of like structs in C, but not really. Objects, like C structs, use nominal typing. This means that given objects A and B (where B is not a subclass of A), A can not be substituted for B, and B can not be substituted for A, even if they have the same fields. Tuples, on the other hand, use structural typing. If a tuple C contains the same fields as tuple D, they are interchangeable. This is a feature not present in C.
Tuples and Objects in Nim are kind of like structs in C, but not exactly. Objects, like C structs, use nominal typing. This means that given objects A and B (where B is not a subclass of A), A can not be substituted for B, and B can not be substituted for A, even if they have the same fields. Tuples, on the other hand, use structural typing. If a tuple C contains the same fields as tuple D, they are interchangeable. This is a feature not present in C.
### Interfacing C and Nim
See [Foreign Function Interface](http://nim-lang.org/docs/manual.html#foreign-function-interface)
See [Foreign function interface](http://nim-lang.org/docs/manual.html#foreign-function-interface).
### Converting C code to Nim
See [c2nim](https://github.com/nim-lang/c2nim/blob/master/doc/c2nim.rst)
See [c2nim](https://github.com/nim-lang/c2nim/blob/master/doc/c2nim.rst).
### Cheat Sheet
Note: Code examples are not exactly one-to-one, there may be subtle differences in the semantics. See comments.
**Note:** Code examples are not exactly one-to-one, there may be subtle differences in the semantics. See comments.
<table>
<tr>
@ -170,7 +169,7 @@ when false:
<b>Single line comments</b>. Use the hash char (#).
<br>
<br>
<b>Multi-line comments</b>. Readability vs easy of use?
<b>Multi-line comments</b>. Readability vs ease of use?
</td>
</tr>
<tr>
@ -188,7 +187,7 @@ var y2 = 2
let z = 2
</pre>
</td>
<td><b>Define variable</b>. y2 uses type inference. z is single-assignment. In Nim, uninitialized variables is initialized to 0/nil or similar defaults.</i>
<td><b>Define variable</b>. y2 uses type inference. z is single-assignment. In Nim, uninitialized variables are initialized to 0/nil or similar defaults.</i>
</td>
</tr>
@ -231,7 +230,7 @@ echo "byte ", $int(a),
"\nA" & $a & "B"
</pre>
</td>
<td><b>Newlines and chars</b>. In nim you can't use ``\n`` as a character literal, because on the Windows platform it expands to CR+LR. So you need to specify which char to use.</i>
<td><b>Newlines and chars</b>. In Nim, you can't use ``\n`` as a character literal, because on Windows, it expands to CR+LF. Thus, you need to specify which char to use.</i>
</td>
</tr>
@ -269,7 +268,7 @@ var x = if foobar(): 42
</pre>
</td>
<td>
<i>If-statements return the value of the expression they evaluate to, so Nim doesn't need a </i><b>ternary operator</b>.</i>
<i>if statements return the value of the expression they evaluate to, so Nim doesn't need a </i><b>ternary operator</b>.</i>
</td>
</tr>