Re: symbol table changes for private functions, classes, etc.

[John W. Eaton]

I've just checked in a largeish change on the object-branch in the
Octave CVS archive that includes all my recent symbol table changes.
I think things are much cleaner now.  Private functions, class
constructors, and class methods are all resolved now.  I kept support
of autoload and the existing typename dispatch (though we may want to
rethink dispatch once we have more complete support for classes).

Please note that the code I checked in is still a bit of a rough draft
and some things are no longer working.  For example, I disabled who,
whos, builtin, and a few other things.  Most of these are not hard,
but I am out of time at the moment and wanted to check things in.
There is only one new test failure, and that is related to the builtin
functions which is currently disabled.  The code that decides whether
a function is out of date and needs reloading is still mostly working
(it was probably never really right for all cases before) but some
things like finding updated subfunctions when they are referenced from
function handles doesn't work properly now (it should be fixed
relatively soon though).

About all you can do with a class object at this point is create one
and pass it to a method.  For example:

  @foo/foo.m:
  
    function r = foo ()
      r = class (struct (), "foo");
    endfunction

  @foo/meth.m:

    function meth (a)
      printf ("hello world, this is @foo/meth.m\n");
    endfunction

Class name resolution is currently based on the first argument only.

Methods (and now all .m or .oct or .mex files in the path) can
overload built-in functions.  The new lookup order is:

  variable
  subfunction
  private function
  class constructor
  class method
  legacy dispatch
  command-line function
  autoload function
  function on the path
  built-in function

The tree_identifier class still caches a symbol_record object from a
particular scope for fast(er) variable access.  If the object is not
defined as a variable when the code is executed, the interpreter then
looks for a function (possibly evaluating the argument list at this
point for dispatch).

Earlier when I posted my idea for implementing all of this, David
Batemen expressed some concern about the possible impact on
performance.  I didn't notice much trouble for simple function calls
using the approach I outlined.  But performance was terrible if there
were many variables, or if the number of scopes became large.  For 
example, the performance for deeply nested recursion was horrible
because each new recursive call generated a new scope and many
lookups.  I fixed these problems by creating a map of symbol_record
objects that handles variables (one map for each function) and a
separate map for functions.

The current symbol table code relies heavily on function inlining to
acheive reasonable performance.  Compiled with -O2, the new code
executes the recursive function that Luis Ortiz posted here:

  https://www.cae.wisc.edu/pipermail/octave-maintainers/2007-April/002591.html

in about the same time as before on my system.  Unfortunately, it is
not faster (or really significantly slower) but I can see a few
opportunities for improvement (but again, I have no time at the moment
for performance tweaking; I need to get the basics working first).
Thanks to Luis for posting this or I might not have noticed how bad
the performance was with my original design.

The symbol_table class is implemented like a singleton object, but
there can be multiple internal instances (I'm sure there is a more
specific pattern name for this, but I'm too lazy to look it up at the
moment).  Access to the table is done via static functions that know
which particular symbol_table instance to use based on an integer
scope tag.  I think the code that searches for symbol definitions is
much easier to follow now.

I plan to move on to some of the more interesting parts of the object
system next.

If you'd like to take a look at these new features, check out the
object-branch from the public Octave CVS archive.

I would like to get 3.0 released soon so these object changes can be
merged with the CVS trunk before the object-branch and the trunk
diverge too much and merging the changes becomes harder.

Once 3.0 is released, we can create a separate branch for 3.0.x patch
releases if necessary.  This branch would be for serious bugs
(fixes for crashes, or 2+2=5 sorts of show stopping bugs only).  Then
I would plan for 3.1 to include the object changes and probably more
graphics improvements.

Comments?

jwe