diff options
author | rumpf_a@web.de <> | 2009-10-21 10:20:15 +0200 |
---|---|---|
committer | rumpf_a@web.de <> | 2009-10-21 10:20:15 +0200 |
commit | 053309e60aee1eda594a4817ac8ac2fb8c18fb04 (patch) | |
tree | 0f1ce8b0de0b493045eb97eeca6ebf06542de601 /doc/effects.txt | |
parent | 581572b28c65bc9fe47974cfd625210a69be0f3f (diff) | |
download | Nim-053309e60aee1eda594a4817ac8ac2fb8c18fb04.tar.gz |
version 0.8.2
Diffstat (limited to 'doc/effects.txt')
-rwxr-xr-x | doc/effects.txt | 41 |
1 files changed, 41 insertions, 0 deletions
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. + + |