Re: More subfunction scoping issues.

[David Bateman]

John W. Eaton wrote:
> 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.

The nesting works as if they were sub-functions. Thus in octave

function f ()
  function g ()
  end
end

if equivalent to

function f()
end
function g()
end

This isn't really a bug, but rather a difference to the way matlab does
it, so I'd say leave it alone.

> 
> | 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

I'm a complete LEX/YACC novice and so the mention of the parser scares
me off a bit. I believe that sub-functions have a symbol in the symbol
table like "f:g". I therefore suppose that given the output of matlab
that nested functions might have an entry in the symbol table like
"f/g". This raises interesting possibilities like sub-functions of
nested functions (ie "f/g:h") and nested functions in sub functions (ie
"f:g/h") which are different.

I suppose we need an additional symbol table called for example
parent_symbol_table, that is a copy of the parent table at the time the
nested function is called. Given the example I posted function handles
of nested-functions need to save the parent symbol table and share it
with other nested-functions saved as function handles. This seems quite
messy to get right. Getting it all right and hooking it in to the parser
might be a little hard for me given my lack of LEX/YACC coding experience.

> 
> 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.

Fine with me


D.