> Shelby Moore wrote: >> Are closures in NekoVM broken in a very harmful way? Read to the >> bottom... >> >> > <snip> >> 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? >> > <snip> > > No, not impossible. I ran into this problem myself, as I wanted closures > in my language to behave more like Lua closures, where variables inside > a closure can reference variables in a lexically enclosing scope > > Essentially, you just do as this post suggests: > http://lists.motion-twin.com/pipermail/neko/2005-August/000470.html > > Variables that need to be accessed inside a function are turned into > members of an array. Modifying the array members inside the function > modifies the values outside the function as well. > > var a = $array(2) > > a[0] = "hello" > a[1] = "world" > > var f = function(string) { > a[0] = string > } > > f("goodbye") > > $print(a[0]) //prints "goodbye" > > > > It took some effort to get this done efficiently (that is, not turning > _every_ variable into an array member, but just those that need to be), > but it does work.
Thus if the closure variables are objects or arrays isn't it unnecessary to use that workaround? Actually the example you provided above implies 'yes' (at least for arrays). I assume the example above uses arrays instead of objects, because array member access is faster. I am happy there is a workaround, and as explained in the link you provided, it is even probably feasible to modify Neko to Lua's style should that be necessary. In my opinion, at least the workaround should be documented (at least on that comparison page to Lua, perhaps also on the specification page), so that prospective new users won't formulate a negative opinion (as I almost did). Please note that I say 'users', to imply a larger target audience (e.g. myself) than only language implementors reading about Neko, because Neko is also a target platform of languages such as HaXe which might inherit the closure implementation of the target platform? (and I will be today posting a new question on the HaXe list to inquire how HaXe implements closures on each platform). After my prior post, I also got to thinking about how references could be simulated for closures. Is it true that in Neko every object and array value is a reference to the instance? In other words, to get a copy of an object or array, one must instantiate a new empty object or array, and copy the members over (and recursively if you want a deep copy). And is the private copy of an object or array variable for each closure, thus also a reference to the instance (assume so, since would be most efficient to copy existing reference, as instance has to be GC any way)? Thus I concluded that there was no problem with objects and arrays (and thus all data structures are contained with them). -- Neko : One VM to run them all (http://nekovm.org)
