Re: more compatibility changes

[John W. Eaton]

On 11-Jul-2003, Paul Kienzle <address@hidden> wrote:

| >  * Remove the built-in variable whitespace_in_literal_matrix and only
| >    implement Matlab-compatible behavior, or make the default value
| >    "traditional" for Matlab compatibility.
| >
| >    I don't think that eliminating whitespace_in_literal_matrix would
| >    cause trouble for code distributed with Octave since it should
| >    already work with any setting of this variable.  Also, we already
| >    have a warn_separator_insert to allow warnings to be printed in
| >    cases like [eye (n)], but it should probably be improved to only
| >    warn about cases that are potenially troublesome (like the example
| >    above) and not things like [1 2].
| 
| Agreed.  The warning is only when the function is first loaded,
| not every time it is run, right?

Yes, it is only printed once when the code is parsed.

| >My current preference would be to remove these variables entirely
| >rather thanjust changing the default values so that we no longer have
| >to worry about trying to make code work for different settings.
| >
| There are way too many of these, so I'm all for removing
| those that you can.

I'm not too worried about the ones that just change the way something
is printed, or that control warnings.  It's the ones like
whitespace_in_literal_matrix that cause trouble.  I still think the
Matlab behavior is a bit flaky, but I no longer think it is worth the
trouble to fight it.

| For backward compatibility purposes (I don't want to force
| users to upgrade Octave to use OctaveForge), I will have to
| assume that these things have the appropriate value and hope
| that people update their site startup file.

It should never hurt to set variables like

  do_fortran_indexing = 1;

in a startup file, even if the built-in variable doesn't exist.  Or
were you thinking of some other kind of problem?

| Or I could replace code like
| 
|   dfi = do_fortran_indexing;
| 
| with
| 
|   dfi = property('do_fortran_indexing')
| 
| where property() is something like
| 
|   function v = property(name)
|     if exist(name)
|       v = eval('name');
|     else
|       v = [];
|     endif
|   end

I suppose you could do that if you like.  It wouldn't bother me to
tell people that the versions of OctaveForge and Octave need to
"match", at least around the time of these changes.  I don't think it
will be a problem for very long, but maybe there are many more
problems than I think.  My hope at this point is that any differences
with Matlab syntax and semantics will be getting smaller so fewer of
these changes will be needed in the future.  But as Dirk's signature
used to say:  prediction is very difficult, especially about the
future.

jwe