Re: DEFVARs in .oct files

[John W. Eaton]

On 10-Feb-2006, Paul Kienzle wrote:

| I believe I have made several suggestions over the years,  none of
| them completely capturing good behaviour.
| 
| Today I would lean toward reducing the number of symbols in the
| global namespace, either by putting the flags in a structure or
| by defining something like a set function to set/restore them.
| The structure syntax is cleaner than a function call with quotes
| around each name.
| 
| Having a system which allows you to remove flags without changing
| user code would be useful.  If the user queries a non-existent flag,
| return [].  If the user sets a non-existent flag, then ignore it.
| Allow packages to add their own flags, presumably in a package
| namespace so that conflicting names are not a problem.
| 
| E.g.,
| 
|       env.misc.editor='vi';
|      env.misc.default_license='GPL';
|      env.gnuplot.replot = 1;
| 
| One question is whether you want the flag to affect only the
| current context, or if it should also change the global context.
| There used to be a lot of the former (e.g., empty_list_elements_ok)
| which meant that well behaved functions needed unwind_protect
| for a number of flags.  Fortunately most of these are gone now, so
| I'm no longer asking for a system to restrict the change to the
| current context.

A structure might be nice, but I was thinking of a simpler change.

Also, rather than a single set function, I just meant that instead of
built-in variables with special semantics, we could have functions to
do the same.  So instead of automatic_replot being a varaible, it
would be a function.  I think the only thing we lose here is the
ability to write things like

  automatic_replot = 0;

Insteaed, you would have to write

  automatic_replot (0);

to set the value.

This change would also apply for things like pi, inf, nan, etc.,
except for "constants" defined using functions, there would be no
corresponding way to set them.  So

  pi (1)

would be an error.  This is exactly what Matlab does now (too many
input arguments).

Also, it seems that for the latest in compatibility, things like inf
and nan need to be functions anyway because you can now write things like

  inf ('double')
  inf ('single')
  inf (n)
  inf (m, n)

etc. in Matlab.

So, if we make the change that I'm proposing, compatibility would be
enhanced, special "variables" like this could be defined by anyone in
a way that is consistent with the way internal "variables" are
defined, all DEFVARs would be replaced by DEFUNs, and I think we could
also eliminate all the symbols_of_XXX functions.  The only downside
that I can see is that the current way of setting built-in variables
would no longer work.

jwe