Mixing name/value pair syntax

In a Matlab seminar a few years ago, I asked why function calls that mix old style and new style name/value pair syntax would only work in a certain order. Specifically, the old style pairs must come first in the argument list. When the order is reversed, an error is thrown as illustrated below.

testFunc('A',10, B=20)

    A: 10
    B: 20

testFunc(B=20, 'A',10)

Unsupported use of the '=' operator. To compare values for equality, use '=='. To pass name-value arguments using the name=value format, provide these arguments after all other inputs.

A MathWorker at the seminar told me that this was by design, but there was no time for him to elaborate. Can anyone think why this would have been a deliberate design choice?

function testFunc(opts)
arguments
   opts.A=1;
   opts.B=2;
end

disp(opts)

end

[Rik]

The only thing I can come up with is the risk of typos, but I don't see how requiring this order would affect that.

If you supply these options with varargin they will result in a cellstr (with string if you use Name=Value). I don't see why that would affect this at all, but maybe it is related? Would the order change anything?

Unrelatedly: I think it is neat you can keep the output of a previous run, even if your edit-and-rerun results in a syntax error.

testFunc('A',10, B=20)

    {'A'}    {[10]}    {["B"]}    {[20]}

testFunc(B=20,'A',10)

Unsupported use of the '=' operator. To compare values for equality, use '=='. To pass name-value arguments using the name=value format, provide these arguments after all other inputs.

function testFunc(varargin)
disp(varargin)
end

[dpb]

I "know nutink!" really, but I have presumed it would be owing to keeping the internal parser less complicated if it can make the assumption that paired/named arguments are last.

[Matt J]

Just as follow-up, one arguably negative consequence of this is that only old-style name/value pairings can be overriden programmatically using comma-separated list expansion, e.g.,

override={'B',10};

testFunc('B', 20 , override{:}) %Successful override

    A: 1
    B: 10

testFunc(B=20 , override{:}) %Forbidden

Unsupported use of the '=' operator. To compare values for equality, use '=='. To pass name-value arguments using the name=value format, provide these arguments after all other inputs.

function testFunc(opts)
arguments
   opts.A=1;
   opts.B=2;
end

 disp(opts)

end

[dpb]

As a follow-up to my earlier, there are usages buried in MATLAB internal functions that rely on the convention as well, optional arguments in the input list are located by finding the location of the first name that matches one of the allowable options and then split off from there to the end of the list and checked for being an even number for starters.

Changing the convention would require a major amount of rework.

[Rik]

That doesn't make sense to me. I must admit I don't know how this interacts with the arguments block (which I don't personally use), but with varargin the Name=Value syntax is forwarded as a cellstr. To me that means your suggested protected case shouldn't be affected. Can you perhaps explain what I'm missing?

[Matt J]

Changing the convention would require a major amount of rework.

I don't see how. The only difference between new-style and old style pair parsing is that now an '=' sign becomes a possible delimiter of the input arguments, in addtition to commas. It should be easy to preconvert the argument list from new style to old style and do whatever it is you used to do. I can code that right now:

convert(" B=20, 'A',10 ")

ans = "'B' , 20 ,  'A' , 10  "

function strOldStyle=convert(strNewStyle)

 [str,m]=strsplit(strNewStyle,["=",","]);
 
 idx=(m=="=");
 
 m(idx)=",";
 
 str(idx)="'"+ strtrim(str(idx))+"'";
 
 strOldStyle = strjoin([str;m,""]);
 

end

[dpb]

It's not the delimiter, it's the order that classical must all go first.

[Matt J]

But we're trying to understand why that is necessary, right? Why is it necessary when you can easily pre-map any argument list to the classical syntax?

[dpb]

There are just a lot of places to go make the adjustment, though. Conceptually, it could be kludged that way, but MATLAB has a lot of functions to deal with. Unless there might be some super high-level way to intercept every call, I suppose. But that would seem to add quite a bit of overhead.

[Matt J]

Isn't there a centralized parser that handles the syntax analysis of an mfile? Why would that be split?

[Rik]

Isn't there a single parser that looks for syntax errors? Why would the naive approach of making the Name=Value syntax work the same as {:} cause any issues anywhere? And why there be a requirement for Name=Value to be last either way?

Only partially on topic: I think the monstrosity below shows how poorly I understand what is happening.

tryme(A=10)

A = "A"

B = 10

function tryme(A,B)
arguments
   A=1;
   B=2;
end
A
B
end

[Matt J]

I think the monstrosity below shows how poorly I understand what is happening.

Nothing monstrous there. As you noted earlier, the A=10 syntax gets converted to a comma-separated pair {"A",10} and so the call is equivalent to,

args={"A",10};

tryme(args{:})

I might have expected,

 args = {'A',10}

so that's a little strange.