From 053309e60aee1eda594a4817ac8ac2fb8c18fb04 Mon Sep 17 00:00:00 2001
From: "rumpf_a@web.de" <>
Date: Wed, 21 Oct 2009 10:20:15 +0200
Subject: version 0.8.2

---
 doc/effects.txt | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100755 doc/effects.txt

(limited to 'doc/effects.txt')

diff --git a/doc/effects.txt b/doc/effects.txt
new file mode 100755
index 000000000..85de1ffdf
--- /dev/null
+++ b/doc/effects.txt
@@ -0,0 +1,41 @@
+=====================================================================
+               Side effects in Nimrod
+=====================================================================
+
+Note: Side effects are implicit produced values! Maybe they should be
+explicit like in Haskell?
+
+
+The idea is that side effects and partial evaluation belong together:
+Iff a proc is side effect free and all its argument are evaluable at
+compile time, it can be evaluated by the compiler. However, really
+difficult is the ``newString`` proc: If it is simply wrapped, it 
+should not be evaluated at compile time! On other occasions it can
+and should be evaluted:
+
+.. code-block:: nimrod
+  proc toUpper(s: string): string =
+    result = newString(len(s))
+    for i in 0..len(s) - 1:
+      result[i] = toUpper(s[i])
+
+No, it really can always be evaluated. The code generator should transform
+``s = "\0\0\0..."`` back into ``s = newString(...)``. 
+
+
+``new`` cannot be evaluated at compile time either. 
+
+
+Raise statement
+===============
+
+It is impractical to consider ``raise`` a statement with side effects.
+
+
+Solution
+========
+
+Being side effect free does not suffice for compile time evaluation. However,
+the evaluator can attempt to evaluate at compile time. 
+
+
-- 
cgit 1.4.1-2-gfad0