Lack of function_handle arrays

The lack of function_handle arrays feels really problematic (arguably a bug), especially now that dictionaries have started to become more first class.

You can create a dictionary with function_handle values no problem,

dict = configureDictionary("string","function_handle");
dict("a") = @(a) a;
dict("b") = @(a) b;

But if you go and ask for the values, Matlab throws an error!

>> dict.values
Unable to combine entry parts.

The workaround is to make a dictionary with cells as values, and wrap each function handle in a cell array.

[Voss]

Do you have a question?

[Jeffrey]

Good point; I answered my own question. I posted this as a service to others who might encounter this issue (and just now filed a bug report) because I generally find question and answers on this forum to be useful. Is it best to just delete this post?

[MarKf]

I guess Community Answers is an easy and accessible place to complain (without the intention of requesting changes or new features that is).

but also

dict = configureDictionary("string","function_handle");
dict("a") = @(a) a;
dict("b") = @(a) b;
values(dict,"cell")

ans = 2×1 cell array
    {@(a)a}
    {@(a)b}

[Jeffrey]

@MarKf Much more elegant workaround---thank you!

[Matt J]

If you had function handle arrays, how would indexing work? How would you decide whether an expression like fArray(i) was an indexing operation or a function call?

Answer 1

[Walter Roberson]

Suppose you have

f = @(x)x+1

then what is

f(1)

?

If hypothetically matlab supported function handle arrays then because every scalar is an array of size 1 then it would follow that f(1) would refer to the first function handle in the array and so would be that handle to @(x)x+1 . But function handle invocation is also () so it would also mean invoking the handle with parameter 1

Or are you proposing that the meaning of () indexing of a function handle array would depend upon whether it was nonscalar? If so then how would you pass a single function handle to code that expected an array of function handles?

There is a fundamental clash in semantics if you permit nonscalar function handle arrays, and the only way out would be to change matlab to use different syntax for invocation compared to indexing. Which would cause its own problems.

[Jeffrey]

I totally agree it's problematic! I find Matlab's OO design quite flawed (but getting better!), and this is another example of an inconsistency in the overall design.

This works great in swift,

var closureArray = [{print("a")},{print("b")}]
closureArray[0]()

and is how this was done in objective-c, and I'm sure other languages as well.

Answer 2

[Steven Lord]

No, this is not a bug. In the past, prior to release R14, you could in fact have had an array of function handles. The decision to no longer allow arrays of function handles, to require using a cell array if you wanted to hold multiple function handles, was a conscious one to avoid some ambiguity especially once anonymous functions were introduced in R14.

Suppose hypothetically you were able to create an array of function handles. Since none of this works today in MATLAB I'm going to write the code that you would run if it did but leave it all commented out.

%{
n = 3;
for k = 1:n
  fh(k) = @(x) sin(k*x);
end
%}

What would you expect this command to do?

% fh(1)

If you said return the vector [sin(1), sin(2), sin(3)] by plugging 1 in for x in each of the function handles, it could do that. But then you wouldn't be able to retrieve any of the individual function handles through indexing.

Okay, so maybe we index into the array then evaluate it by allowing nested parentheses indexing. That wouldn't work either.

% fh(2)(pi)

fh(2) would return a smaller array of function handles. Then the (pi) operation would index into that smaller array using pi which would error. You could make an argument that () should do indexing unless you're using it on a scalar, in which case it should be interpreted as execution. But special cases like that are notorious for tripping up users. In the first section of code I wrote above, fh(1) would be interpreted differently depending on whether the value of n was 3 or 1. So you'd need to guard fh(1) with calls to isscalar or something similar.

[Jeffrey]

Whether you want to call it a bug or not, it's certainly not great design that a method call on a correctly initialized dictionary can fail just because it's holding onto a particular type of value. This falls into that same category of "notorious for tripping up users" (it just did).

But also, I would definitely make the argument that behavior like the swift example I gave above, is far more intuitive, and consistent with other programming languages. That said, I certainly agree with you that the current design makes this situation awkward---but it doesn't mean it can't be better!