From c20a9086f607cfcc699958d3aaeb40e8662f06f3 Mon Sep 17 00:00:00 2001
From: Søren Sandmann Pedersen <ssp@redhat.com>
Date: Fri, 31 Jan 2014 08:07:54 -0500
Subject: TODO: expressions with gotos in them

---
 TODO | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/TODO b/TODO
index 05d4933..79e97aa 100644
--- a/TODO
+++ b/TODO
@@ -1,3 +1,63 @@
+* Expressions with goto in them
+
+  A simple example is
+
+      F() { goto blah; }
+
+      print 7 + F();
+
+      @blah:;
+
+  where we jump to blah, leaving 7 on the stack.
+
+  There is another case, captured in popbug3.nl, where we keep
+  returning from the same function. Each time the result is added to
+  something popped from the stack. This results in a stack underflow.
+
+  Part of the solution will have to be to keep a reference to the
+  expression stack. This of course implies that popping the stack can't
+  actually remove the stack entries.
+
+  A different problem is if the stack references a variable. Should
+  that variable be evaluated every time? My intuition says no. Consider
+
+       ret: label = null;
+
+       x = 0;
+
+       F() { ret = back; @back: return 10; }
+
+       print x + F();
+
+       x++;
+
+       if (x < 100)
+       	  goto ret;
+
+   if you do this, F() will return 100 times, but the evaluation of
+   the 'x' in 'x + F()' will be skipped every time.
+
+   It seems the expression stack will have to become a tree with heap
+   allocated entries. An environment will then contain a pointer to a
+   node of this tree.
+
+   What does this mean for the bytecode? For example, an ADD operation
+   should now take the two values on top of the stack and create a new
+   value whose 'next' pointer is the same as the next pointer of the
+   second value on the stack.
+
+   Should this be done at the bytecode level? It may be that there
+   should be separate 'dynamic' versions of all the stack ops. These
+   might operate on a leaf pointer on the stack.
+
+   In the case where we can detect that an expression doesn't escape,
+   the array based stack could then be used. Is detection as simple as
+   there being no function calls in the expression? And no
+   statement-expressions, presumably.
+
+   This will have to be considered an optimization.
+
+
 - Short-term tasks:
 
   - Test suite
-- 
cgit v1.2.3