Are closures in NekoVM broken in a very harmful way? Read to the bottom...
> I am undecided if continuations are worth the effort? Generators seem > quite useful, but could be implemented more efficiently than generalized > continuations. > > I noticed that Lua supports coroutines (a potential use of continuations), > which they claim are useful for implementing multi-tasking on devices > which do not supporting pre-emptive multi-threading, or for lower overhead > multi-tasking: NekoVM already supports multiple instances, so one could implement cooperative (i.e. manual instead of pre-emptive context switch) multi-threaded/multi-tasking manually if necessary (just run multiple instances of same bytecode, then manually call from the bytecode to the NekoVM API to switch between instances/contexts): http://lists.motion-twin.com/pipermail/neko/2010-January/002724.html [snip] > continuations could greatly simplify web coding: > > http://en.wikipedia.org/w/index.php?title=Continuation&oldid=339611728#Continuations_in_Web_development > > I can remember some of my complex nested blocks of Javascript code to deal > with asynchronous loading of code via XMLHttpRequest (or dynamically > loading the <script> tag), where the nesting could I presume be eliminated > with continuations. Perhaps this can be solved (I think I did) with > closures and Continuation-passing style, or specialized shared state and > dispatch on asynchronous events, or separate thread for loading each > resource (again needing to maintain shared state negotiation), but it > might be less general or more convoluted. > > I assume MMOG (massively multiplayer online games) may also have to deal > with asynchronous network resources. Continuations will not provide any benefit over closures with callbacks (i.e. first class functions), except when the state of call stack is needed. When blocking (waiting) on an asynchronous resource (i.e. event), then to obtain multi-tasking one is going to need a callback whether they use continuations or not. Thus, the only difference between use of closures and continuations, is that the continuation will save the call stack, in addition to the local and global scoped variables. So continuations will not be needed unless the action one needs to do after the asynchronous event requires the complexity of the logic of the stack trace (e.g. recursive algorithm or tree graph). And continuations can be simulated by simulating the stack in a data structure. That is good news for NekoVM. However, NekoVM does not correctly implement closures: http://nekovm.org/lua?s=closure#closures NekoVM is copying the closure variables instead of saving a reference to a shared copy, and thus there is no way to correctly use externally scoped (shared by other scopes) variables. How is anyone going to implement recursion or tree graphs on asynchronous events/resources in NekoVM, when each function closure gets its own private copy of the data structure? Thus I think it is impossible in NekoVM? Apparently this design decision was done to optimize GC. And I repeat that this is why reference counting combined with Bacon's GC is apparently a superior memory mgmt scheme: http://lists.motion-twin.com/pipermail/neko/2010-January/002691.html -- Neko : One VM to run them all (http://nekovm.org)
