Re: More format() changes

[Rik]

On 10/15/2019 10:44 PM, Kai Torben Ohlhus wrote:
> On 10/16/19 1:39 PM, Rik wrote:
>> All,
>>
>> Per suggestions, I changed the behavior of format when called with no
>> arguments to also include setting the uppercase_format variable to the
>> default (https://hg.savannah.gnu.org/hgweb/octave/rev/2545345f8bd9). 
>> Subsequently, I changed format to accept multiple arguments
>> (https://hg.savannah.gnu.org/hgweb/octave/rev/1ef42010c53b).  It is now
>> possible to set everything in one line.  For example, "format long e
>> compact uppercase".
>>
>> --Rik
>>
> Thank you again Rik.  The resetting to default is now pretty
> understandable.  No objections.  On the other hand, setting many options
> may require much more error validation as the following scenario shows:
>
> ## Initial state
>>> [a, b, c] = format
> a = short
> b = loose
> c = lowercase
>
> ## Works, this is actually pretty nice compared to Matlab!
>>> format long e uppercase compact
>>> [a, b, c] = format
> a = longe
> b = compact
> c = uppercase
>
> ## My stupid input #1
>>> format long e uppercase compact short
>>> [a, b, c] = format
> a = short
> b = compact
> c = uppercase
>
> The most right one has "won".

I'm okay with this behavior.  As with a light switch, you can turn it on,
off, on, off, on and it is always the last choice that prevails.  I also
think this is a pretty rare occurrence, and I would rather code for the 99%
path rather than the 1% path.  However, if it is really bothersome someone
could add a boolean that records when a format has been specified and raise
an error if this happens more than once.

>
> ## My stupid input #2
>>> format long e lowercase loose shor
> error: format: unrecognized format state 'shor'
>>> [a, b, c] = format
> a = short
> b = loose
> c = lowercase
>
> Especially #2 is very surprising to me.  There was an error, but changes
> happened.  This is due to the way the arguments are handled one by one...
There might be some relatively simple ways to handle this, although I need
a little guidance from jwe.  One method might be to use a C++ try/catch
around the existing code.  We would need to save and restore quite a few
variables (12).  Alternatively, we could use Octave's own unwind_protect
class and the protect_var method, but I'm not sure if that does what we
want in this instance which is to let the change happen, unless an error is
thrown, in which case the variable needs to be restored.  Last choice would
simply be to shadow the 12 file static variables with function local
copies, and then copy the local changes over only at the end of the
function if no error has resulted.  The last method involves the most code
re-writing, whereas the other two might be as simple as wrapping the
existing code unchanged within a block.

>
> I am afraid, that Matlab intentionally lets the users enter those format
> options exclusively.  For the sake of simplicity, maybe Octave should
> have this limitation, as well?  There are too many evil combinations to
> consider :-/
I understand the reasoning, but let's not be governed by what Matlab does. 
They have made poor architectural choices in the past and I don't want to
be constrained by that reality.

--Rik