implement incremental lists via fusion & stepped sub-expression interpretation about rep_lang HOT 4 CLOSED

potential sources of bugs:

• variable de-aliasing may cause variable capture

from rep_lang.

I now have a sketch of the toplevel API for SSEI.

it's a little funky, because we basically are evaluating "one lambda at a time", either in normal interpretation mode, or in SSEI incremental mode (for each variable), until we reach an atomic value (non lambda) which cannot be evaluated further.

example:

(defn coeffSum
  (lam [coeff]
    (lam [xs]
      (* coeff
         (foldl + 0 xs)))))

so here our first argument is a single integer, coeff, which will not be SSEI-able (because it's not a list, just a single value). our second argument, xs, could be SSEI-d, because it's a list of numbers.

they way I'm imagining we will interpret this is to first process coeff via the "normal interpreter". in this case, that will evaluate the application of a lambda to some value, creating a binding for coeff in the interpreter's environment. then we will het the inner lambda and return it.

there will be a strange dance between the caller and the callee to discover that the inner function is SSEI-able, and the caller will provide an iterator to incrementally provide those values.

from rep_lang.

it is looking increasingly like laziness is the way to go. which means that SSEI would get scrapped.

fusion, however, will likely be incorporated at some point.

from rep_lang.

the completion of #34 subsumes / eclipses / removes necessity of this.

from rep_lang.