René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Not all closures necessarily need to be allocated on the heap.","articleBody":"After flattening in dumbjs, closures are turned into javascript objects. Then all variables that need to be in a closure are accessed and updated through the similarly-named properties in those objects.\n\nIt is known that it's impossible to implement closures by storing them solely on the stack. This is because it's impossible to cover all of their features without placing them on the heap. It is also necessary to have a garbage collector that will destroy them after they're not necessary anymore.\n\nHowever, there are cases where a closure may be created on the stack. For example:\n\n```\nvar one = 1;\nfunction addOne(x) {\n  return x + one\n}\nconsole.log(addOne(1))\nconsole.log(addOne(2))\n```\n\nThe `addOne` function doesn't outlive its relevant stack frame. As such, its closure (containing just the variable called `one`) could live in the stack.\n\nThis is advantageous in examples such as the one above, since allocating this structure on the heap would mean more work for the garbage collector, and slower access to its values.\n\nAnother example:\n\n```\nvar count = 0\n[1,2,3].forEach(function addToCount (val) { count += val })\n```\n\nThe function `addToCount` above is passed to another function (`forEach`), but it doesn't outlive the stack frame because `forEach` returns before this stack frame is done and doesn't store `addToCount` anywhere. This is another example in which a function's closure can be declared on the stack for faster access.\n","author":{"url":"https://github.com/fabiosantoscode","@type":"Person","name":"fabiosantoscode"},"datePublished":"2016-01-31T11:28:50.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/2/js2cpp/issues/2"}