Re: saveing/loading symbol table of annymous functions

[John W. Eaton]

On 11-Apr-2007, David Bateman wrote:

| John W. Eaton wrote:
| > I'm not sure why we were duplicating the data for a function directly
| > in the tree_anon_fcn_handle class, so I've checked in the following
| > change.  Now the tree_anon_fcn_handle object just contains an
| > octave_user_function object that contains the parameter list, function
| > body, return list, and symbol table.
| >
| > The octave_fcn_handle class has an octave_value object that contains
| > the function.  You can extract a pointer to the user function object
| > and then get the symbol table from there using the new
| > octave_user_function::sym_tab method.  Does that give you everything
| > you need to write the load/save functions for anonymous function
| > handles?
| >
| > Thanks,
| >
| > jwe
| >
| >   
| Ok, I took a quick look at how to go about saving and then reloading the
| local symbol table of a function handle, and have implemented it for the
| case of "save {-text|-binary|-hdf5}" in the attached patch, including
| unit test code. I treated the fact that for
| 
| a = 2;
| f = @(x) = a+x;
| f(1)
| save -text test.mat f
| 
| the local symbol table of "f" after the evaluation "f(1)" has two
| undefined symbol records "__retval__" and "x" by excluding undefined
| symbol records when saving anonymous function handles.
| 
| I also tried to handle backwards compatibility by only saving the symbol
| table if needed. Therefore
| 
| g = @(x) 2 * x;
| save -text test.mat g
| 
| can be saved if this patch is applied and read by older versions of
| octave. The reverse is also true. However, anonymous function handles
| such as "f" above were never saved correct as the symbol table wasn't
| saved. So there is no backward compatibility in that case. To do this
| for the binary type I included the length of the symbol table in the
| function name like "@<anonymous> 2" if the symbol table has two
| elements. For text files I added a keyword "length" and the hdf5 files
| added an attribute "SYMBOL_TABLE" with the length of the symbol table.

I'm not too concerned about backward compatibility here since I don't
think loading and saving function handles ever worked properly in the
past.  But I don't see that the extra information can cause trouble,
so please check in this patch.

Thanks,

jwe