|
From: | John W. Eaton |
Subject: | refactoring variable storage |
Date: | Thu, 3 Jan 2019 22:21:08 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 |
To fix this problem, I recently began a significant refactoring to move the storage of values from the symbol table to the call stack. This makes much more sense and is consistent with the way I understand other interpreters and complied languages typically work. With the new approach for storing values, accessing data from non-local scopes (nested functions accessing variables from parent functions) and data in parent stack frames is much simpler. Creating proper closures should be much more manageable, and should allow bug #39257 (handles to nested functions are not yet supported) to be fixed (finally!).
The patches for these changes are on the jwe-call-stack-refactor bookmark in the mercurial archive publicly accessible here: http://hg.octave.org/octave-jwe
There are approximately 80 smaller changesets that make up the complete set of changes. These changes are not all self-contained or rational as many were made at temporary checkpoints during development. If merged together, the resulting diff is about 12,000 lines. I'm inclined to apply it as one large changeset since at this point I don't know how to break it up into smaller chunks that make sense.
Some details about the implementation are included at the top of the stack-frame.h file and before each class declaration in that file.
One way or another, I'd like to merge these changes with the default branch soon so they can be thoroughly tested before Octave 6 is released sometime later in 2019 or early 2020.
Comments and questions welcome. jwe
[Prev in Thread] | Current Thread | [Next in Thread] |