From 105f266e31fae18c70ade51d1378584ba547650b Mon Sep 17 00:00:00 2001
From: Andreas Baumann <mail@andreasbaumann.cc>
Date: Thu, 5 May 2022 20:36:28 +0200
Subject: notes about short-citcuting logic in boolean expression small
 bugfixes in documentation

---
 miniany/README.html | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

(limited to 'miniany/README.html')

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>
-- 
cgit v1.2.3-54-g00ecf