More subfunction scoping issues.

[John W. Eaton]

On 30-Mar-2007, David Bateman wrote:

| John and All,
| 
| John recently introduced a number of fixes for subfunction scoping
| issues, that vastly improvement the compatibility between octave and
| matlab. However, there remains a few issues that need to be addressed to
| get the compatibility to be 100%. Consider the test function
| 
| function toto2 ()
|   x = toto(23)
|   x.titi(1)
|   x.titi(1)
|   x.titi(1)
|   x.tata()
|   x.c
| end
| 
| function y = toto (a)
|   y.titi = @titi;
|   y.tata = @tata;
|   y.c = 1;
|   function p = titi (q)
|     p = q + a;
|     a = a + y.c;
|     y.c = y.c + 1;
|   end
|   function z = tata()
|     z = tutu();
|     function z = tutu ()
|       z = y.c;
|     end
|   end
| end

Nested functions (like titi and tata above) are not currently
supported by Octave.  So I suppose this should be rejected by the
parser rather than accepted and thus misleading you to think that it
should work.

| Of course with octave it crashes on the first call to "titi" as the
| variable "a" that is in the scope of the parent of titi is not visible
| in the scope of titi. What would be needed to fix this issue, as I've
| just been given a large chunk of matlab code that relies on these
| scoping rules? So if the effort isn't much I wouldn't mind attacking
| this issue rather than modifying the code I've been given to allow
| easier exchange with the people giving me the code.

First, the parser needs to properly recognize the nesting of the
functions and (given the current symbol table implementation) somehow
store the function objects in the fbi symbol table with names that
reflect the nesting.  This has to be done in a way that doesn't
conflict with subfunctions.  I think Matlab requires that if any
"function" token in a file has a matching "end" token, then all
functions in the file must also have "end" tokens.  Then it should be
easy to see whether the functions are nested.  As a special case, if
none of the "function" tokens have matching "end" tokens, then you
have subfunctions instead of nested functions.  Maybe clearer:

  function f ()           ## nested functions
    function g ()
    end
  end

  function f ()           ## subfunctions
  end
  function g ()
  end

  function f ()           ## g is a nested function of f and
    function g ()         ## h is a subfunction of f
    end                   ## (I think this should work but I haven't
  end                     ## tried it)
  function h ()
  end

  function f ()           ## subfunctions
    ...
  function g ()
    ...

  function f ()           ## error, mismatched end.
    ...
  function g ()
    ...
  end

In any case, while I think it is fine to work on this now, merging
changes to handle nested functions should be done after 3.0 (unless
you find a way to do it that does not require the invasive changes I
expect will be required).  If you'd like, open a branch for it.

jwe