[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More subfunction scoping issues.
From: |
John W. Eaton |
Subject: |
More subfunction scoping issues. |
Date: |
Sat, 31 Mar 2007 14:37:24 -0400 |
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