octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nested functions patch


From: Max Brister
Subject: Re: Nested functions patch
Date: Sat, 10 Mar 2012 13:47:17 -0700

| Instead of handling this in the symbol table lookup code, how about
| simply ensuring that the symbols are all resolved to the proper scope
| at the time of parsing the functions?  I'm thinking that after parsing
| a function that includes a set of nested functions, you would walk the
| parse tree of each child function, look for tree_identifier objects
| and fix up the references to the symbol table so that they are in the
| proper scope.  Then I think you are done, and no significant changes
| need to be made to the symbol table class itself.   Symbol record
| objects are already tagged if they are formal parameters, so you
| shouldn't need to specifically tag "nonlocal" objects.  Would that
| work?

This approach works with a slight modification, and it is close to
what I had originally planned to do. symbol_table still needed to be
modified significantly. Instead of making variables nonlocal I
modified symbol_table::table to contain the correct symbol_record. My
approach differed slightly from the one you recommend. Instead of
doing walk to modify tree_identifiers, I marked the old symbol_record
as invalid. This prevented the need for a tree walk at the expense of
adding an extra check for validity in tree_identifier::xsym. This
approach fell prey to the problem you mention:

| OK.  So instead of marking variables as nonlocal, I think this
| function should be fixing the scope of variables.  I'm not sure
| whether you can do this only by looking at the symbol tables because
| tree_identfier objects hold a reference to symbol_record objects, so I
| think you'll need to update those.  Hmm, looking at the
| tree_identifier class, it seems that the current definition of
| tree_identifier::xsym will cause trouble because when executing a
| child function, the current scope (at eval time) would be different
| from the scope stored at parse time.  So then the way the xsym
| currently works, the variable would be put back into the child scope,
| which is the one current at the time the child function is evaluated.

On possible fix for this is to put a pointer to the declaring function
(or symbol table of the declaring function?) in the symbol_record.
Then symbol_record::varval/ref can be modified to use the
active_context of their declaring function, which is required for
recursive child functions. Also, tree_identifier::xsym can look at the
active_context of its symbol_record in order to determine when its
cached value is out of date.

| So I'm not sure what the right fix is.  But it seems to me that we
| shouldn't have to search through multiple symbol tables each time a
| function is evaluated.  We should be able to make it so that the
| scope of a variable is resolved when nested functions are parsed.

I agree, searching through multiple symbol tables each time a function
is evaluated is a bad idea. I will try implementing the approach I
have outlined above (unless you have any objections). It may not be
perfect, but I think it is headed in the right direction.

Max Brister


reply via email to

[Prev in Thread] Current Thread [Next in Thread]