Re: referencing subfunctions

[John W. Eaton]

On 11-Jun-2009, Christian Böhme wrote:

| Jaroslav Hajek wrote:
| 
|  > Can you provide an example of what does not work for you?
| 
| Please see the attached files (map() is the algorithm invoked
| by either broken() or working() both of which accept an arbitrary
| number as their sole argument).
| 
| It appears that - even though section 12.7.2 of the current Octave
| docs does not rule it out per se, ie, that subfunctions may indeed
| reference other subfunctions - there is some sort of function
| definition/visibility nesting level involved with the way function
| files are parsed, which is majorly disturbing to say the least.
| Syntactically, all functions including the one whose name is
| identical to the file's name are on one and the same level yet
| f() does not appear to be visible to any function (including the
| anonymous ones) other than broken().
| 
|  >                                                           AFAIK,
|  > there are no such special tricks in fsolve (note that it is reimplemented
|  > in 3.2.0),
| 
| Turns out that it has nothing to do with fsolve() but with the way
| symbols are made available to other scopes/translation/interpretation
| units.
| 
|  >            so most likely you either see a bug or you're doing
|  > something wrong.
| 
| Maybe, depending on your definition of "wrong" ;)

Is there some previous context for this discussion?

I seem to get the same result for both working and broken with the
current sources (and 3.2.0):

  octave:1> working (1)
  p = 1.000000, x = 1.000000
  p = 3.000000, x = 1.000000
  y = 4.000000
  ans =  4
  octave:2> broken (1)
  p = 1.000000, x = 1.000000
  p = 3.000000, x = 1.000000
  y = 4.000000
  ans =  4

Is this the result you expect?  What version of Octave are you using?
I seem to recall a scoping bug that might have been similar to what
you are reporting, and fixing it, but saying that it would not be
fixed in any 3.0.x release because the symbol table code in Octave has
been completely rewritten, and I see no point in trying to fix the old
code at this point.

jwe