284 lines
9.1 KiB
Markdown
284 lines
9.1 KiB
Markdown
****
|
|
|
|
**DISCLAIMER!**
|
|
Unofficial, work in progress!
|
|
There may be inaccuracies in this guide.
|
|
|
|
***
|
|
|
|
|
|
This is a guide for people with experience in C or a similar language. The guide assumes some intermediate knowledge, for instance of how stacks and heaps works.
|
|
|
|
The general tutorials can be found here:
|
|
http://nimrod-lang.org/tut1.html
|
|
http://nimrod-lang.org/tut2.html
|
|
|
|
The manual provides a more or less complete overview of the language:
|
|
http://nimrod-lang.org/manual.html
|
|
|
|
### At a glance
|
|
|
|
Similarities and differences.
|
|
|
|
Feature | C | Nimrod
|
|
---------------------|-----------------------------------|-----------------------------------------
|
|
Compilation | Machine code | Machine code via C*
|
|
Meta-programming | C Preprocessor | Nimrod (const/when/template/macro)
|
|
Memory Management | Manual (GC w/ libraries or obj-C) | Garbage-collected and manual
|
|
Types | Static | Static
|
|
Dependent types | No | Partial support
|
|
Generics | No (Templates w/ C++) | Yes
|
|
int8/16/32/64 types | Yes | Yes
|
|
Unsigned ints | Yes (by default) | Yes (not by default)
|
|
Arrays | Yes | Yes
|
|
Bounds-checking | No | Yes
|
|
Type inference | No (some w/ C++11) | Yes (extensive support)
|
|
Closures | No (Yes w/ obj-C or C++11) | Yes
|
|
Operator Overloading | No (Yes w/ C++) | Yes (on any types)
|
|
Custom Operators | No | Yes
|
|
Object-Oriented | No (Yes w/C++ or obj-C) | Minimalistic**
|
|
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
|
|
|
|
### Philosophy
|
|
|
|
The key to understanding Nimrod is that Nimrod 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 Nimrod does give you pointers, Nimrod 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 Nimrod 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), Nimrod meta-programming is done with the Nimrod language itself. That means that most Nimrod code can be executed at compile time, and Nimrod's ability to generate Nimrod-code at compile time is much more sophisticated.
|
|
|
|
### Arrays
|
|
|
|
In C an array is more or less syntactic sugar for pointers. In Nimrod, 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 Nimrod, the argument is a read-only reference, meaning it can't be assigned to. Take the following example:
|
|
|
|
**C:**
|
|
|
|
```C
|
|
void foobar(int z[4]) {
|
|
z[5] = 5;
|
|
printf("%d\n",z[5]);
|
|
}
|
|
int main() {
|
|
int x[4] = {1, 2, 3, 4};
|
|
foobar(x);
|
|
printf("%d\n", x[1]);
|
|
return 0;
|
|
}
|
|
```
|
|
|
|
**Nimrod:**
|
|
|
|
```Nimrod
|
|
proc foobar(z: array[0..3, int]) =
|
|
z[5] = 5 # Error: Cannot assign to z
|
|
echo z[5] # Error: Index out of bounds.
|
|
|
|
var x = [1, 2, 3, 4]
|
|
|
|
foobar(x)
|
|
```
|
|
|
|
The C-code will compile, it may or may not crash. The Nimrod 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, Nimrod 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 Nimrod 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.
|
|
|
|
Nimrod 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.
|
|
|
|
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 Nimrod, this is true as well, but you are strongly discouraged from using pointers in Nimrod, and you can accomplish almost everything you'd otherwise use pointers for with normal arguments, "var" arguments, variables, and "ref".
|
|
|
|
### Unsigned integers
|
|
|
|
Nimrod strongly discourages the use of unsigned integers, as it's considered unnecessary and somewhat unsafe* for most applications. The unsigned types uint, uint8/16/32/64 are available by default, but the arithmetic and binary functions are not defined. If you do need to do arithmetic on unsigned integers, you need to import the **unsigned** module.
|
|
|
|
*See: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
|
|
|
|
|
|
### Object-Orientation
|
|
|
|
Objects in Nimrod 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 Nimrod.
|
|
|
|
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.
|
|
|
|
Nimrod does not have an implicit _this_/_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 Nimrod. These are at the moment mostly work-in-progress.
|
|
|
|
### Structs - Tuples and Objects
|
|
|
|
Tuples and Objects in Nimrod are kind of like structs in C, but not really.
|
|
|
|
### Interfacing C and Nimrod
|
|
|
|
See [Foreign Function Interface](http://nimrod-lang.org/manual.html#foreign-function-interface)
|
|
|
|
### Converting C code to Nimrod
|
|
|
|
See [c2nim](http://nimrod-lang.org/c2nim.html)
|
|
|
|
### Cheat Sheet
|
|
Note: Code examples are not exactly one-to-one, there may be subtle differences in the semantics. See comments.
|
|
|
|
<table>
|
|
<tr>
|
|
<th>C</th><th>Nimrod</th><th>Comment</th>
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
int x;
|
|
int y = 2;
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
var x : int
|
|
var y1 : int = 2
|
|
var y2 = 2
|
|
let z = 2
|
|
</pre>
|
|
</td>
|
|
<td><b>Define variable</b>. y2 uses type inference. z is single-assignment. In nimrod, uninitialized variables is initialized to 0/nil or similar defaults.</i>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
char* s = "Hello World.";
|
|
char s0 = s[0]; // 'H'
|
|
char *t = s; // Ptr to s
|
|
s[11] = '!';
|
|
// s, t == "Hello World!"
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
var s = "Hello World."
|
|
var s0: char = s[0] # 'H'
|
|
var t = s # Copy of s
|
|
s[11] = '!'
|
|
# s is "Hello World!"
|
|
# t is "Hello World."
|
|
</pre>
|
|
</td>
|
|
<td><b>Strings and char</b>. Strings are pass-by-value (copied on assignment) and strictly bounds-checked on access.</i>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
char a = '\n';
|
|
printf("byte %d\nA%cB\n",
|
|
a, a);
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
let a = '\L'
|
|
echo "byte ", $int(a),
|
|
"\nA" & $a & "B"
|
|
</pre>
|
|
</td>
|
|
<td><b>Newlines and chars</b>. In nimrod 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>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
9 % 8 // 1
|
|
-9 % 8 // -1
|
|
(unsigned)(-9) %
|
|
(unsigned)(8) // 7
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
9 mod 8 # 1
|
|
-9 mod 8 # -1
|
|
-9 %% 8 # 7
|
|
</pre>
|
|
</td>
|
|
<td><b>Modulo operator</b>. <i>%% treats its argument as unsigned numbers. <a href="http://nimrod-lang.org/manual.html#pre-defined-integer-types">See</a></i></i>
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
int x = foobar() ? 42 : 0;
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
var x = if foobar(): 42
|
|
else: 0
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<i>If-statements return the value of the expression they evaluate to, so Nimrod doesn't need a </i><b>ternary operator</b>.</i>
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
void foo() {
|
|
printf("Hello World\n");
|
|
}
|
|
int bar() {
|
|
return 2;
|
|
}
|
|
int baz(int x) {
|
|
return x*2;
|
|
}
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
proc foo() =
|
|
echo "Hello World"
|
|
|
|
proc bar() : int =
|
|
2
|
|
|
|
proc baz(x : int) =
|
|
x*2
|
|
</pre>
|
|
</td>
|
|
<td><b>Function/Procedure.</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
void foobar(person_t *a) {
|
|
person_t b;
|
|
b = *a;
|
|
b.name = "Bob";
|
|
*a = b;
|
|
}
|
|
</pre>
|
|
</td>
|
|
<td>
|
|
<pre>
|
|
proc foobar(a: ref TPerson) =
|
|
var b: TPerson
|
|
b = a[]
|
|
b.name = "Bob"
|
|
a[] = b
|
|
</pre>
|
|
</td>
|
|
<td><b>Dereference.</b> <i>In C, only the pointer to the strings in the struct is copied. In Nimrod, the string is also copied, but refs are not deep-copied.</i> </td>
|
|
</tr>
|
|
|
|
|
|
</table> |