Re: Nested functions patch

[Max Brister]

Thank you for taking a look at my patch. Sorry about the lack of
conformance to style. I will fix this.

| For
|
|  function f ()
|    x = 1
|    g (x)
|    x
|    function g (x)
|      x = 2
|    end
|  end
|  f ()
|
| I see the following:
|
|  x =  1
|  x =  2
|  error: `x' undefined near line 4 column 3
|  error: called from:
|  error:   f at line 4, column 3
|
| I think X should still be defined to be 1 after the call to G.

You are correct. I forgot to take into account the fact that
parameters are never nonlocal (the segfault is disturbing). I will
look into how parameters are handled, and hopefully this will not be
too difficult to fix. Additionally, I will try to add some more
aggressive test cases.

Furthermore, adding new variables in a parent function may cause
issues. For example,
function f ()
  eval ('x = 1');
        g ()
  function g ()
    x
  endfunction
endfunction

I am not sure how this should be handled. Matlab handles this by
simply erroring on eval('x = 1'). I could just mark all children of g
as having nonlocal x instead. Also, a similar problem comes up if a
variable in a parent function is cleared.

| A symbol table is not a function.  Do you mean that nest_parent is the
| symbol table for the parent function?  If so, I'm not sure that makes
| sense.  There should be one symbol table with multiple scopes, one for
| each function.  So it seems to me that you would want to track scopes
| rather than symbol table objects.
|
| Thinking about this more, when we have nested functions, don't the
| children effectively have the same scope as the parent, except that
| variables passed in the argument list or as globals are handled
| separately?  So would it be possible to handle nested functions by
| merging the scopes of the parents and children?  I suppose we would
| have to be sure that the parents do not have access to the symbols
| that appear only in the child functions.  But if the child and parent
| shared the same scope, then it seems that it would simplify variable
| lookup in the child.

Yes, I did mean that nest_parent is the symbol table for the parent
function. Unfortunatly, a simple collaplsing of the symbol table will
not work. For example,

function f ()
  g ()
  function g ()
    y = 1;
    e ();
    y
  endfunction
  function e ()
    y = 2;
  endfunction
endfunction

should result should be y = 1 after the call to e. However, if y was
used in f the result would be y = 2. Resolving these differences gets
more complex as the nesting depth and breath increase. I think the
simplest approach in this case is to just continue the practice of
using one symbol table per scope. Otherwise, I think our scope class
would end up looking almost exactly like the symbol table class.

I think a better way to resolve nonlocal lookups. symbol_record_ref
could be modified to add a symbol_record local_ref field. For nonlocal
variables this would be a reference to the symbol_table record for
which they are local.

| What is the intent of the update_nest function?

The intent of the update_nest function is to determine which variables
are nonlocal in a given symbol_table. update_nest gets executed once
on the parent function after parsing is complete. It then recursively
calls update_nest sending each child a set of local variables. Then
each child marks the local variables of its parent as nonlocal.

I am on spring break next week, and may not always have a fast
computer or internet connection available. I will try to fix all of
the issues you pointed out and produce another patch.

Max Brister