notes about short-citcuting logic in boolean expression

small bugfixes in documentation

2 files changed, 31 insertions, 13 deletions

diff --git a/miniany/README.html b/miniany/README.html
index c40d9f8..a736885 100644
--- a/miniany/README.html
+++ b/miniany/README.html
@@ -182,7 +182,7 @@ cat c4.c4 EOF c4.c EOF cc.c EOF hello.c | ./c4
 </ul>
 <p>Requirements</p>
 <ul>
-<li>on the hosted Linux envorinment we need syscalls to <i>syscal</i>, <i>int </i><i>0x80</i>, etc.</li>
+<li>on the hosted Linux envorinment we need syscalls to <i>syscall</i>, <i>int </i><i>0x80</i>, etc.</li>
 <li>we need inline assembly to create to syscalls</li>
 </ul>
 <p>Alternative:</p>
@@ -261,7 +261,13 @@ cat c4.c4 EOF c4.c EOF cc.c EOF hello.c | ./c4
 <p>Implementation status: no</p>
 <p>Reasoning:</p>
 <ul>
-<li>Don't allow non-blocked if/else, just avoid then dangling else problem, it's uninteresting and in C not as bad as in PASCAL-like languages, as the block markers are just one character big.</li>
+<li>Don't allow non-blocked if/else, just avoid the dangling else problem, it's uninteresting and in C not as bad as in PASCAL-like languages, as the block markers are just one character big.</li>
+</ul>
+<h3>Short-circuit conditions</h3>
+<p>Implementations status: yes</p>
+<p>Reasoning:</p>
+<ul>
+<li>Not really necessary as we could get away with <i>if( </i><i>a </i><i>!= </i><i>null </i><i>) </i><i>{ </i><i>if( </i><i>a-&gt;x </i><i>== </i><i>7 </i><i>) </i><i>{ </i><i>... </i><i>} </i><i>}</i>, but it makes code look rather ugly.</li>
 </ul>
 <h3>Return statement</h3>
 <p>Implemention status: yes, but..</p>
@@ -269,7 +275,8 @@ cat c4.c4 EOF c4.c EOF cc.c EOF hello.c | ./c4
 <ul>
 <li>There are good reasons not to allow <i>return </i>everywhere in the code, see newest Oberon revisions allowing <i>RETURN </i>only at the end of the function declaration. There are benefits like easier detection whether the function returns a function, easier flow analysis (image <i>returns </i>in complicated <i>if-else</i>-statements). For now we allow it everywhere, but we should try hard not to use it in the middle of code blocks.</li>
 <li>There is an argument from the code correctness point of view as <i>return </i>in the middle of code makes the code hard to reason about (similar to too many if-else-statements)</li>
-<li>Error handling is really hard, for now we check only whether we see a <i>return </i>at all anywhere in the body.</li>
+<li>Allowing <i>return </i>only at the end of a function and nowhere else makes tail-recursion easy.</li>
+<li>Error handling is really hard when <i>return </i>appears everywhere in the body, it's much easier to check whether there is a <i>return </i>at the end and whether the returned type matches the prototype of the function,</li>
 </ul>
 <h3>Register Allocation</h3>
 <p>Implementation status: yes</p>
@@ -277,6 +284,10 @@ cat c4.c4 EOF c4.c EOF cc.c EOF hello.c | ./c4
 <ul>
 <li>Compared to a stack machine even the simplest register allocation algorithm produces much better code</li>
 </ul>
+<p>Counter arguments:</p>
+<ul>
+<li>Stack machine with the top of stack in EAX is also quite a simple solution.</li>
+</ul>
 <h3>Abstract Syntax Trees</h3>
 <p>Implementation status: yes</p>
 <p>Reasoning:</p>
diff --git a/miniany/cc.wg b/miniany/cc.wg
index 09ac15d..e686dd4 100644
--- a/miniany/cc.wg
+++ b/miniany/cc.wg
@@ -29,16 +29,16 @@ WordGrinder dumpfile v3: this is a text file; diff me!
 .clipboard.margin: 0
 .clipboard.viewmode: 1
 .clipboard.wordcount: 6
-.documents.1.co: 6
-.documents.1.cp: 191
-.documents.1.cw: 21
+.documents.1.co: 9
+.documents.1.cp: 134
+.documents.1.cw: 10
 .documents.1.margin: 0
 .documents.1.name: "main"
 .documents.1.sticky_selection: false
 .documents.1.viewmode: 1
-.documents.1.wordcount: 2988
+.documents.1.wordcount: 3073
 .fileformat: 8
-.findtext: "Note"
+.findtext: "syscal,"
 .menu.accelerators.^@: "ZM"
 .menu.accelerators.^B: "SB"
 .menu.accelerators.BACKSPACE: "ZDPC"
@@ -141,7 +141,7 @@ WordGrinder dumpfile v3: this is a text file; diff me!
 .menu.accelerators.ZU: "UP"
 .menu.accelerators.ZWL: "^LEFT"
 .menu.accelerators.ZWR: "^RIGHT"
-.name: "/media/sd/abaumann/projects/compilertests/miniany/cc.wg"
+.name: "/home/abaumann/projects/compilertests/miniany/cc.wg"
 .replacetext: ""
 .statusbar: true
 .current: 1
@@ -282,7 +282,7 @@ LB not type-safe
 LB only used for (s)printfs string manipulation and output functions
 LB C4 doesn't implement variable arguments for defining functions, so we cannot bootstrap a freestanding version
 P Requirements
-LB on the hosted Linux envorinment we need syscalls to syscal, int 0x80, etc.
+LB on the hosted Linux envorinment we need syscalls to syscall, int 0x80, etc.
 LB we need inline assembly to create to syscalls
 P Alternative:
 LB create simple functions like putchar, putint, putstring (one per basic type) and some helpers like putnl
@@ -333,17 +333,24 @@ LB for bootstrapping the operating system we might need unions (as well as packi
 H3 Dangling else
 P Implementation status: no
 P Reasoning:
-LB Don't allow non-blocked if/else, just avoid then dangling else problem, it's uninteresting and in C not as bad as in PASCAL-like languages, as the block markers are just one character big.
-H3 Return statement
+LB Don't allow non-blocked if/else, just avoid the dangling else problem, it's uninteresting and in C not as bad as in PASCAL-like languages, as the block markers are just one character big.
+H3 Short-circuit conditions
+P Implementations status: yes
+P Reasoning:
+LB Not really necessary as we could get away with if( a != null ) { if( a->x == 7 ) { ... } }, but it makes code look rather ugly. 
+H3 Return statement
 P Implemention status: yes, but..
 P Reasoning:
 LB There are good reasons not to allow return everywhere in the code, see newest Oberon revisions allowing RETURN only at the end of the function declaration. There are benefits like easier detection whether the function returns a function, easier flow analysis (image returns in complicated if-else-statements). For now we allow it everywhere, but we should try hard not to use it in the middle of code blocks.
 LB There is an argument from the code correctness point of view as return in the middle of code makes the code hard to reason about (similar to too many if-else-statements)
-LB Error handling is really hard, for now we check only whether we see a return at all anywhere in the body.
+LB Allowing return only at the end of a function and nowhere else makes tail-recursion easy.
+LB Error handling is really hard when return appears everywhere in the body, it's much easier to check whether there is a return at the end and whether the returned type matches the prototype of the function,
 H3 Register Allocation
 P Implementation status: yes
 P Reasoning:
 LB Compared to a stack machine even the simplest register allocation algorithm produces much better code
+P Counter arguments:
+LB Stack machine with the top of stack in EAX is also quite a simple solution.
 H3 Abstract Syntax Trees
 P Implementation status: yes
 P Reasoning: