implement expression handling further

+ Add some notes about returning functions that I started thinking about
  as a result of the fib example

1 files changed, 33 insertions, 0 deletions

diff --git a/README.md b/README.md
index f61dfdb..9e40e96 100644
--- a/README.md
+++ b/README.md
@@ -83,3 +83,36 @@ If (big if) this experiment turns out to be useful on some level I'll probably
 slowly try to make it more self-reliant. My target would be systems programming,
 possibly even embedded systems, though I don't yet know if this 'paradigm' is
 powerful enough or if I might need some escape hatches like `unsafe` in Rust.
+
+### Really, not returns?
+
+Semantically, yes, although it is useful to convert certain closure calls to
+equivalent return statements where possible. This reduces stack usage if nothing
+else, and existing compilers are more used to return-oriented programming so it
+might also be possible that the produced assembly is more efficient.
+
+As an example, see `examples/fib.fwd`. The naive C++ currently generated
+(besides not actually compiling due to template instantiation depth, heh)
+converts what's usually a binary tree of successive calls into a linear sequence
+that takes up a huge amount of stack memory. However, we can note that a closure
+call is equivalent to a return when
+
+1. the function has only one closure parameter
+2. all code paths end in the closure call
+3. the closure call does not reference any local variables by reference
+    (except references that were taken as parameters)
+
+Our fibonacci function matches all these cases, and could theoretically be
+turned into a more typical return-oriented function for great benefit. Checking
+these requirements should be relatively straightforward.
+
+We could potentially loosen up these requirements, for example we could allow
+multiple closure parameters and just return a variant, although the caller now
+has to pattern match on the result. Taking things even further, we could start
+treating functions more as macros and just replace the function call with the
+function body, although this has some other, more fuzzy, requirements like not
+allowing recursion.
+
+We might even want to require that a function can be turned into a 'returning'
+function (being pretentious we might prefer calling it 'folding' but anyway) so
+that it can be interfaced from C code, for example.