sleep close_call is too much - expression is sufficient since executes in the same context.

docs/scarpet/language/SystemFunctions.md

@@ -100,7 +100,9 @@ from other threads, just because the only possibility of a deadlock in this case
 bad code, not the internal world access behaviour. Some things tough like players or entities manipulation, can be 
 effectively parallelized.
 
-If the app is shutting down, creating new tasks via `task`
+If the app is shutting down, creating new tasks via `task` will not succeed. Instead the new task will do nothing and return
+`null`, so most threaded application should handle closing apps naturally. Keep in mind in case you rely on task return values,
+that they will return `null` regardless of anything in these situations.
 
 ### `task(function, ... args)`, `task_thread(executor, function, ... args)`
 
@@ -120,22 +122,22 @@ a = 3; task_thread('temp', _(outer(a), b) -> foo(a,b), 5)
     => Another example of running the same thing passing arguments using closure over anonymous function as well as passing a parameter.
 </pre>
 
-### `sleep()` `sleep(timeout)`, `sleep(timeout, close_call, ... args)`
+### `sleep()` `sleep(timeout)`, `sleep(timeout, close_expr)`
 
 
 Halts the execution of the thread (or the game itself, if run not as a part of a task) for `expr` milliseconds. 
 It checks for interrupted execution, in that case exits the thread (or the entire program, if not run on a thread) in case the app
-is being stopped/removed. If the closing call is specified, executes the following function when a shutdown signal is triggered.
-If run on the main thread (not as a taks) the call may only be invocated when the entire game shuts down, so close call only 
-makes sense for threads. For programs use `__on_close()` handler.
+is being stopped/removed. If the closing expression is specified, executes the expression when a shutdown signal is triggered.
+If run on the main thread (i.e. not as a task) the close expression may only be invoked when the entire game shuts down, so close call only 
+makes sense for threads. For regular programs, use `__on_close()` handler.
 
-Since `close_call` is executed after app shutdown is initiated, you won't be able to create new tasks in that block. Threads
+Since `close_expr` is executed after app shutdown is initiated, you won't be able to create new tasks in that block. Threads
 should periodically call `sleep` to ensure all app tasks will finish when the app is closing or right after, but the app engine
-will not forcefully remove your running tasks so the tasks themselves need to properly react to the closing request.
+will not forcefully remove your running tasks, so the tasks themselves need to properly react to the closing request.
 
 <pre>
 sleep(50)  # wait for 50 milliseconds
-sleep(1000, _() -> print('Interrupted')) # waits for 1 second, outputs a message when thread is shut down.
+sleep(1000, print('Interrupted')) # waits for 1 second, outputs a message when thread is shut down.
 </pre>
 
 ### `task_count(executor?)`