Would it be desireable to support continuations?  And if yes, would this
be added at (.n) bytecode interpreter or in the (.neko) compiler?

http://en.wikipedia.org/w/index.php?title=Continuation&oldid=336969568#First-class_continuations

Am I correct that implementing continuations is similar to forming a
closure, in that a copy of the current stack is saved to capture the local
variables (execution context)?  Also the resume location in the executable
statements is also saved.  If the function capturing the continuation
contains a return statement (i.e. has any branch of execution that can
return instead of resuming a captured continuation), then the entire stack
history has to be saved also?  Also if this is all true, then how can a
register (not stack) VM, such as Lua 5.0+, implement generalized
continuations?

Generators are also an interesting feature:

http://en.wikipedia.org/w/index.php?title=Generator_%28computer_science%29&oldid=335080836#Python
http://squirrel-lang.org/doc/squirrel2.html#generators

Generators can be implemented with continuations if continuations are
allowed to recieve a value when resumed.  The caller can pass its
continuation as an argument, then called function can yield by resuming
the caller's continuation which receives the called function's
continuation.  When the caller resumes the called function's continuation,
the called function will resume the caller's continuation on next
iteration of loop, which receives the next iterated value.

Thus, wouldn't continuations be a more generalized abstraction than Neko's
goto?

Neko does currying and mentions this is important for supporting
functional programming.  Are not generators or continuations important for
implementing list comprehension and lazy evaluation, which are key
features of some functional programming?

http://en.wikipedia.org/w/index.php?title=Generator_%28computer_science%29&oldid=335080836#See_also

Note in a purely referentially transparent language such as Haskell,
closures and continuations are not explicitly available in the language
because there is no defined state (except external state abstracted in a
Monad), nevertheless there are continuations (thunks) that are formed from
lazy evaluation.  How can these be implemented in Neko without
continuations?

Off topic, note that pure lazy evaluation (lack of defined state and order
of operations) leads to "space leaks", for which I have proposed a
generalized solution (which was accepted as a feature request by the
creators of Haskell):

http://www.coolpage.com/commentary/economic/shelby/Functional_Programming_Essence.html#Allocation_Size_Determinism

--
Neko : One VM to run them all
(http://nekovm.org)

Reply via email to