procs.txt 21 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696
  1. Procedures
  2. ==========
  3. What most programming languages call `methods`:idx: or `functions`:idx: are
  4. called `procedures`:idx: in Nim. A procedure
  5. declaration consists of an identifier, zero or more formal parameters, a return
  6. value type and a block of code. Formal parameters are declared as a list of
  7. identifiers separated by either comma or semicolon. A parameter is given a type
  8. by ``: typename``. The type applies to all parameters immediately before it,
  9. until either the beginning of the parameter list, a semicolon separator or an
  10. already typed parameter, is reached. The semicolon can be used to make
  11. separation of types and subsequent identifiers more distinct.
  12. .. code-block:: nim
  13. # Using only commas
  14. proc foo(a, b: int, c, d: bool): int
  15. # Using semicolon for visual distinction
  16. proc foo(a, b: int; c, d: bool): int
  17. # Will fail: a is untyped since ';' stops type propagation.
  18. proc foo(a; b: int; c, d: bool): int
  19. A parameter may be declared with a default value which is used if the caller
  20. does not provide a value for the argument.
  21. .. code-block:: nim
  22. # b is optional with 47 as its default value
  23. proc foo(a: int, b: int = 47): int
  24. Parameters can be declared mutable and so allow the proc to modify those
  25. arguments, by using the type modifier `var`.
  26. .. code-block:: nim
  27. # "returning" a value to the caller through the 2nd argument
  28. # Notice that the function uses no actual return value at all (ie void)
  29. proc foo(inp: int, outp: var int) =
  30. outp = inp + 47
  31. If the proc declaration has no body, it is a `forward`:idx: declaration. If the
  32. proc returns a value, the procedure body can access an implicitly declared
  33. variable named `result`:idx: that represents the return value. Procs can be
  34. overloaded. The overloading resolution algorithm determines which proc is the
  35. best match for the arguments. Example:
  36. .. code-block:: nim
  37. proc toLower(c: char): char = # toLower for characters
  38. if c in {'A'..'Z'}:
  39. result = chr(ord(c) + (ord('a') - ord('A')))
  40. else:
  41. result = c
  42. proc toLower(s: string): string = # toLower for strings
  43. result = newString(len(s))
  44. for i in 0..len(s) - 1:
  45. result[i] = toLower(s[i]) # calls toLower for characters; no recursion!
  46. Calling a procedure can be done in many different ways:
  47. .. code-block:: nim
  48. proc callme(x, y: int, s: string = "", c: char, b: bool = false) = ...
  49. # call with positional arguments # parameter bindings:
  50. callme(0, 1, "abc", '\t', true) # (x=0, y=1, s="abc", c='\t', b=true)
  51. # call with named and positional arguments:
  52. callme(y=1, x=0, "abd", '\t') # (x=0, y=1, s="abd", c='\t', b=false)
  53. # call with named arguments (order is not relevant):
  54. callme(c='\t', y=1, x=0) # (x=0, y=1, s="", c='\t', b=false)
  55. # call as a command statement: no () needed:
  56. callme 0, 1, "abc", '\t' # (x=0, y=1, s="abc", c='\t', b=false)
  57. A procedure may call itself recursively.
  58. `Operators`:idx: are procedures with a special operator symbol as identifier:
  59. .. code-block:: nim
  60. proc `$` (x: int): string =
  61. # converts an integer to a string; this is a prefix operator.
  62. result = intToStr(x)
  63. Operators with one parameter are prefix operators, operators with two
  64. parameters are infix operators. (However, the parser distinguishes these from
  65. the operator's position within an expression.) There is no way to declare
  66. postfix operators: all postfix operators are built-in and handled by the
  67. grammar explicitly.
  68. Any operator can be called like an ordinary proc with the '`opr`'
  69. notation. (Thus an operator can have more than two parameters):
  70. .. code-block:: nim
  71. proc `*+` (a, b, c: int): int =
  72. # Multiply and add
  73. result = a * b + c
  74. assert `*+`(3, 4, 6) == `*`(a, `+`(b, c))
  75. Export marker
  76. -------------
  77. If a declared symbol is marked with an `asterisk`:idx: it is exported from the
  78. current module:
  79. .. code-block:: nim
  80. proc exportedEcho*(s: string) = echo s
  81. proc `*`*(a: string; b: int): string =
  82. result = newStringOfCap(a.len * b)
  83. for i in 1..b: result.add a
  84. var exportedVar*: int
  85. const exportedConst* = 78
  86. type
  87. ExportedType* = object
  88. exportedField*: int
  89. Method call syntax
  90. ------------------
  91. For object oriented programming, the syntax ``obj.method(args)`` can be used
  92. instead of ``method(obj, args)``. The parentheses can be omitted if there are no
  93. remaining arguments: ``obj.len`` (instead of ``len(obj)``).
  94. This method call syntax is not restricted to objects, it can be used
  95. to supply any type of first argument for procedures:
  96. .. code-block:: nim
  97. echo "abc".len # is the same as echo len "abc"
  98. echo "abc".toUpper()
  99. echo {'a', 'b', 'c'}.card
  100. stdout.writeLine("Hallo") # the same as writeLine(stdout, "Hallo")
  101. Another way to look at the method call syntax is that it provides the missing
  102. postfix notation.
  103. The method call syntax conflicts with explicit generic instantiations:
  104. ``p[T](x)`` cannot be written as ``x.p[T]`` because ``x.p[T]`` is always
  105. parsed as ``(x.p)[T]``.
  106. **Future directions**: ``p[.T.]`` might be introduced as an alternative syntax
  107. to pass explict types to a generic and then ``x.p[.T.]`` can be parsed as
  108. ``x.(p[.T.])``.
  109. See also: `Limitations of the method call syntax`_.
  110. Properties
  111. ----------
  112. Nim has no need for *get-properties*: Ordinary get-procedures that are called
  113. with the *method call syntax* achieve the same. But setting a value is
  114. different; for this a special setter syntax is needed:
  115. .. code-block:: nim
  116. type
  117. Socket* = ref object of RootObj
  118. FHost: int # cannot be accessed from the outside of the module
  119. # the `F` prefix is a convention to avoid clashes since
  120. # the accessors are named `host`
  121. proc `host=`*(s: var Socket, value: int) {.inline.} =
  122. ## setter of hostAddr
  123. s.FHost = value
  124. proc host*(s: Socket): int {.inline.} =
  125. ## getter of hostAddr
  126. s.FHost
  127. var s: Socket
  128. new s
  129. s.host = 34 # same as `host=`(s, 34)
  130. Command invocation syntax
  131. -------------------------
  132. Routines can be invoked without the ``()`` if the call is syntatically
  133. a statement. This command invocation syntax also works for
  134. expressions, but then only a single argument may follow. This restriction
  135. means ``echo f 1, f 2`` is parsed as ``echo(f(1), f(2))`` and not as
  136. ``echo(f(1, f(2)))``. The method call syntax may be used to provide one
  137. more argument in this case:
  138. .. code-block:: nim
  139. proc optarg(x: int, y: int = 0): int = x + y
  140. proc singlearg(x: int): int = 20*x
  141. echo optarg 1, " ", singlearg 2 # prints "1 40"
  142. let fail = optarg 1, optarg 8 # Wrong. Too many arguments for a command call
  143. let x = optarg(1, optarg 8) # traditional procedure call with 2 arguments
  144. let y = 1.optarg optarg 8 # same thing as above, w/o the parenthesis
  145. assert x == y
  146. The command invocation syntax also can't have complex expressions as arguments.
  147. For example: (`anonymous procs`_), ``if``, ``case`` or ``try``. The (`do
  148. notation`_) is limited, but usable for a single proc (see the example in the
  149. corresponding section). Function calls with no arguments still needs () to
  150. distinguish between a call and the function itself as a first class value.
  151. Closures
  152. --------
  153. Procedures can appear at the top level in a module as well as inside other
  154. scopes, in which case they are called nested procs. A nested proc can access
  155. local variables from its enclosing scope and if it does so it becomes a
  156. closure. Any captured variables are stored in a hidden additional argument
  157. to the closure (its environment) and they are accessed by reference by both
  158. the closure and its enclosing scope (i.e. any modifications made to them are
  159. visible in both places). The closure environment may be allocated on the heap
  160. or on the stack if the compiler determines that this would be safe.
  161. Creating closures in loops
  162. ~~~~~~~~~~~~~~~~
  163. Since closures capture local variables by reference it is often not wanted
  164. behavior inside loop bodies. See `closureScope <system.html#closureScope>`_
  165. for details on how to change this behavior.
  166. Anonymous Procs
  167. ---------------
  168. Procs can also be treated as expressions, in which case it's allowed to omit
  169. the proc's name.
  170. .. code-block:: nim
  171. var cities = @["Frankfurt", "Tokyo", "New York", "Kyiv"]
  172. cities.sort(proc (x,y: string): int =
  173. cmp(x.len, y.len))
  174. Procs as expressions can appear both as nested procs and inside top level
  175. executable code.
  176. Do notation
  177. -----------
  178. As a special more convenient notation, proc expressions involved in procedure
  179. calls can use the ``do`` keyword:
  180. .. code-block:: nim
  181. sort(cities) do (x,y: string) -> int:
  182. cmp(x.len, y.len)
  183. # Less parenthesis using the method plus command syntax:
  184. cities = cities.map do (x:string) -> string:
  185. "City of " & x
  186. # In macros, the do notation is often used for quasi-quoting
  187. macroResults.add quote do:
  188. if not `ex`:
  189. echo `info`, ": Check failed: ", `expString`
  190. ``do`` is written after the parentheses enclosing the regular proc params.
  191. The proc expression represented by the do block is appended to them.
  192. In calls using the command syntax, the do block will bind to the immediately
  193. preceeding expression, transforming it in a call.
  194. ``do`` with parentheses is an anonymous ``proc``; however a ``do`` without
  195. parentheses is just a block of code. The ``do`` notation can be used to
  196. pass multiple blocks to a macro:
  197. .. code-block:: nim
  198. macro performWithUndo(task, undo: untyped) = ...
  199. performWithUndo do:
  200. # multiple-line block of code
  201. # to perform the task
  202. do:
  203. # code to undo it
  204. Nonoverloadable builtins
  205. ------------------------
  206. The following builtin procs cannot be overloaded for reasons of implementation
  207. simplicity (they require specialized semantic checking)::
  208. declared, defined, definedInScope, compiles, sizeOf,
  209. is, shallowCopy, getAst, astToStr, spawn, procCall
  210. Thus they act more like keywords than like ordinary identifiers; unlike a
  211. keyword however, a redefinition may `shadow`:idx: the definition in
  212. the ``system`` module. From this list the following should not be written in dot
  213. notation ``x.f`` since ``x`` cannot be type checked before it gets passed
  214. to ``f``::
  215. declared, defined, definedInScope, compiles, getAst, astToStr
  216. Var parameters
  217. --------------
  218. The type of a parameter may be prefixed with the ``var`` keyword:
  219. .. code-block:: nim
  220. proc divmod(a, b: int; res, remainder: var int) =
  221. res = a div b
  222. remainder = a mod b
  223. var
  224. x, y: int
  225. divmod(8, 5, x, y) # modifies x and y
  226. assert x == 1
  227. assert y == 3
  228. In the example, ``res`` and ``remainder`` are `var parameters`.
  229. Var parameters can be modified by the procedure and the changes are
  230. visible to the caller. The argument passed to a var parameter has to be
  231. an l-value. Var parameters are implemented as hidden pointers. The
  232. above example is equivalent to:
  233. .. code-block:: nim
  234. proc divmod(a, b: int; res, remainder: ptr int) =
  235. res[] = a div b
  236. remainder[] = a mod b
  237. var
  238. x, y: int
  239. divmod(8, 5, addr(x), addr(y))
  240. assert x == 1
  241. assert y == 3
  242. In the examples, var parameters or pointers are used to provide two
  243. return values. This can be done in a cleaner way by returning a tuple:
  244. .. code-block:: nim
  245. proc divmod(a, b: int): tuple[res, remainder: int] =
  246. (a div b, a mod b)
  247. var t = divmod(8, 5)
  248. assert t.res == 1
  249. assert t.remainder == 3
  250. One can use `tuple unpacking`:idx: to access the tuple's fields:
  251. .. code-block:: nim
  252. var (x, y) = divmod(8, 5) # tuple unpacking
  253. assert x == 1
  254. assert y == 3
  255. **Note**: ``var`` parameters are never necessary for efficient parameter
  256. passing. Since non-var parameters cannot be modified the compiler is always
  257. free to pass arguments by reference if it considers it can speed up execution.
  258. Var return type
  259. ---------------
  260. A proc, converter or iterator may return a ``var`` type which means that the
  261. returned value is an l-value and can be modified by the caller:
  262. .. code-block:: nim
  263. var g = 0
  264. proc WriteAccessToG(): var int =
  265. result = g
  266. WriteAccessToG() = 6
  267. assert g == 6
  268. It is a compile time error if the implicitly introduced pointer could be
  269. used to access a location beyond its lifetime:
  270. .. code-block:: nim
  271. proc WriteAccessToG(): var int =
  272. var g = 0
  273. result = g # Error!
  274. For iterators, a component of a tuple return type can have a ``var`` type too:
  275. .. code-block:: nim
  276. iterator mpairs(a: var seq[string]): tuple[key: int, val: var string] =
  277. for i in 0..a.high:
  278. yield (i, a[i])
  279. In the standard library every name of a routine that returns a ``var`` type
  280. starts with the prefix ``m`` per convention.
  281. Overloading of the subscript operator
  282. -------------------------------------
  283. The ``[]`` subscript operator for arrays/openarrays/sequences can be overloaded.
  284. Multi-methods
  285. =============
  286. Procedures always use static dispatch. Multi-methods use dynamic
  287. dispatch. For dynamic dispatch to work on an object it should be a reference
  288. type as well.
  289. .. code-block:: nim
  290. type
  291. Expression = ref object of RootObj ## abstract base class for an expression
  292. Literal = ref object of Expression
  293. x: int
  294. PlusExpr = ref object of Expression
  295. a, b: Expression
  296. method eval(e: Expression): int {.base.} =
  297. # override this base method
  298. quit "to override!"
  299. method eval(e: Literal): int = return e.x
  300. method eval(e: PlusExpr): int =
  301. # watch out: relies on dynamic binding
  302. result = eval(e.a) + eval(e.b)
  303. proc newLit(x: int): Literal =
  304. new(result)
  305. result.x = x
  306. proc newPlus(a, b: Expression): PlusExpr =
  307. new(result)
  308. result.a = a
  309. result.b = b
  310. echo eval(newPlus(newPlus(newLit(1), newLit(2)), newLit(4)))
  311. In the example the constructors ``newLit`` and ``newPlus`` are procs
  312. because they should use static binding, but ``eval`` is a method because it
  313. requires dynamic binding.
  314. As can be seen in the example, base methods have to be annotated with
  315. the `base`:idx: pragma. The ``base`` pragma also acts as a reminder for the
  316. programmer that a base method ``m`` is used as the foundation to determine all
  317. the effects that a call to ``m`` might cause.
  318. In a multi-method all parameters that have an object type are used for the
  319. dispatching:
  320. .. code-block:: nim
  321. type
  322. Thing = ref object of RootObj
  323. Unit = ref object of Thing
  324. x: int
  325. method collide(a, b: Thing) {.base, inline.} =
  326. quit "to override!"
  327. method collide(a: Thing, b: Unit) {.inline.} =
  328. echo "1"
  329. method collide(a: Unit, b: Thing) {.inline.} =
  330. echo "2"
  331. var a, b: Unit
  332. new a
  333. new b
  334. collide(a, b) # output: 2
  335. Invocation of a multi-method cannot be ambiguous: collide 2 is preferred over
  336. collide 1 because the resolution works from left to right.
  337. In the example ``Unit, Thing`` is preferred over ``Thing, Unit``.
  338. **Performance note**: Nim does not produce a virtual method table, but
  339. generates dispatch trees. This avoids the expensive indirect branch for method
  340. calls and enables inlining. However, other optimizations like compile time
  341. evaluation or dead code elimination do not work with methods.
  342. Iterators and the for statement
  343. ===============================
  344. The `for`:idx: statement is an abstract mechanism to iterate over the elements
  345. of a container. It relies on an `iterator`:idx: to do so. Like ``while``
  346. statements, ``for`` statements open an `implicit block`:idx:, so that they
  347. can be left with a ``break`` statement.
  348. The ``for`` loop declares iteration variables - their scope reaches until the
  349. end of the loop body. The iteration variables' types are inferred by the
  350. return type of the iterator.
  351. An iterator is similar to a procedure, except that it can be called in the
  352. context of a ``for`` loop. Iterators provide a way to specify the iteration over
  353. an abstract type. A key role in the execution of a ``for`` loop plays the
  354. ``yield`` statement in the called iterator. Whenever a ``yield`` statement is
  355. reached the data is bound to the ``for`` loop variables and control continues
  356. in the body of the ``for`` loop. The iterator's local variables and execution
  357. state are automatically saved between calls. Example:
  358. .. code-block:: nim
  359. # this definition exists in the system module
  360. iterator items*(a: string): char {.inline.} =
  361. var i = 0
  362. while i < len(a):
  363. yield a[i]
  364. inc(i)
  365. for ch in items("hello world"): # `ch` is an iteration variable
  366. echo ch
  367. The compiler generates code as if the programmer would have written this:
  368. .. code-block:: nim
  369. var i = 0
  370. while i < len(a):
  371. var ch = a[i]
  372. echo ch
  373. inc(i)
  374. If the iterator yields a tuple, there can be as many iteration variables
  375. as there are components in the tuple. The i'th iteration variable's type is
  376. the type of the i'th component. In other words, implicit tuple unpacking in a
  377. for loop context is supported.
  378. Implict items/pairs invocations
  379. -------------------------------
  380. If the for loop expression ``e`` does not denote an iterator and the for loop
  381. has exactly 1 variable, the for loop expression is rewritten to ``items(e)``;
  382. ie. an ``items`` iterator is implicitly invoked:
  383. .. code-block:: nim
  384. for x in [1,2,3]: echo x
  385. If the for loop has exactly 2 variables, a ``pairs`` iterator is implicitly
  386. invoked.
  387. Symbol lookup of the identifiers ``items``/``pairs`` is performed after
  388. the rewriting step, so that all overloads of ``items``/``pairs`` are taken
  389. into account.
  390. First class iterators
  391. ---------------------
  392. There are 2 kinds of iterators in Nim: *inline* and *closure* iterators.
  393. An `inline iterator`:idx: is an iterator that's always inlined by the compiler
  394. leading to zero overhead for the abstraction, but may result in a heavy
  395. increase in code size. Inline iterators are second class citizens;
  396. They can be passed as parameters only to other inlining code facilities like
  397. templates, macros and other inline iterators.
  398. In contrast to that, a `closure iterator`:idx: can be passed around more freely:
  399. .. code-block:: nim
  400. iterator count0(): int {.closure.} =
  401. yield 0
  402. iterator count2(): int {.closure.} =
  403. var x = 1
  404. yield x
  405. inc x
  406. yield x
  407. proc invoke(iter: iterator(): int {.closure.}) =
  408. for x in iter(): echo x
  409. invoke(count0)
  410. invoke(count2)
  411. Closure iterators have other restrictions than inline iterators:
  412. 1. ``yield`` in a closure iterator can not occur in a ``try`` statement.
  413. 2. For now, a closure iterator cannot be evaluated at compile time.
  414. 3. ``return`` is allowed in a closure iterator (but rarely useful) and ends
  415. iteration.
  416. 4. Neither inline nor closure iterators can be recursive.
  417. Iterators that are neither marked ``{.closure.}`` nor ``{.inline.}`` explicitly
  418. default to being inline, but this may change in future versions of the
  419. implementation.
  420. The ``iterator`` type is always of the calling convention ``closure``
  421. implicitly; the following example shows how to use iterators to implement
  422. a `collaborative tasking`:idx: system:
  423. .. code-block:: nim
  424. # simple tasking:
  425. type
  426. Task = iterator (ticker: int)
  427. iterator a1(ticker: int) {.closure.} =
  428. echo "a1: A"
  429. yield
  430. echo "a1: B"
  431. yield
  432. echo "a1: C"
  433. yield
  434. echo "a1: D"
  435. iterator a2(ticker: int) {.closure.} =
  436. echo "a2: A"
  437. yield
  438. echo "a2: B"
  439. yield
  440. echo "a2: C"
  441. proc runTasks(t: varargs[Task]) =
  442. var ticker = 0
  443. while true:
  444. let x = t[ticker mod t.len]
  445. if finished(x): break
  446. x(ticker)
  447. inc ticker
  448. runTasks(a1, a2)
  449. The builtin ``system.finished`` can be used to determine if an iterator has
  450. finished its operation; no exception is raised on an attempt to invoke an
  451. iterator that has already finished its work.
  452. Note that ``system.finished`` is error prone to use because it only returns
  453. ``true`` one iteration after the iterator has finished:
  454. .. code-block:: nim
  455. iterator mycount(a, b: int): int {.closure.} =
  456. var x = a
  457. while x <= b:
  458. yield x
  459. inc x
  460. var c = mycount # instantiate the iterator
  461. while not finished(c):
  462. echo c(1, 3)
  463. # Produces
  464. 1
  465. 2
  466. 3
  467. 0
  468. Instead this code has to be used:
  469. .. code-block:: nim
  470. var c = mycount # instantiate the iterator
  471. while true:
  472. let value = c(1, 3)
  473. if finished(c): break # and discard 'value'!
  474. echo value
  475. It helps to think that the iterator actually returns a
  476. pair ``(value, done)`` and ``finished`` is used to access the hidden ``done``
  477. field.
  478. Closure iterators are *resumable functions* and so one has to provide the
  479. arguments to every call. To get around this limitation one can capture
  480. parameters of an outer factory proc:
  481. .. code-block:: nim
  482. proc mycount(a, b: int): iterator (): int =
  483. result = iterator (): int =
  484. var x = a
  485. while x <= b:
  486. yield x
  487. inc x
  488. let foo = mycount(1, 4)
  489. for f in foo():
  490. echo f
  491. ..
  492. Implicit return type
  493. --------------------
  494. Since inline iterators must always produce values that will be consumed in
  495. a for loop, the compiler will implicitly use the ``auto`` return type if no
  496. type is given by the user. In contrast, since closure iterators can be used
  497. as a collaborative tasking system, ``void`` is a valid return type for them.
  498. Converters
  499. ==========
  500. A converter is like an ordinary proc except that it enhances
  501. the "implicitly convertible" type relation (see `Convertible relation`_):
  502. .. code-block:: nim
  503. # bad style ahead: Nim is not C.
  504. converter toBool(x: int): bool = x != 0
  505. if 4:
  506. echo "compiles"
  507. A converter can also be explicitly invoked for improved readability. Note that
  508. implicit converter chaining is not supported: If there is a converter from
  509. type A to type B and from type B to type C the implicit conversion from A to C
  510. is not provided.