Partial Function Applications: Allow return of function name

[ChristianGruen]

Without wanting to revive #889, an important observation I picked up is that named function references and “partially applied functions without applications” can be considered identical. That is, there should be no reason to distinguish between count#1 and count(?).

Currently, however, partially applied functions are currently defined to lose the reference to the original function and its arity (and some Qt4 tests ensure that this is the case: https://github.com/qt4cg/qt4tests/blob/8649941e0e695ff8fb4cb27c52e99590cc88126f/misc/HigherOrderFunctions.xml#L1933).

From a user perspective, I see no reason why the two cases should be treated differently, and I would argue that we should either treat them identically or (at least) allow implementations to treat them identically, i.e., allowing an implementation to return count for function-name(count(?)).

[michaelhkay]

Currently 4.6.2.3 Partial Function Application says that the name property of the returned function is absent, both for static and dynamic partial application. Are you proposing this should be changed for both cases (static and dynamic)?

The only objection I can see is that someone might assume that if a function item has name=fn:concat and arity=2 then they can assume that the function in question is concat#2, whereas under your proposal it might, for example, be concat(?, '-', ?). It feels a little confusing to me that you can have two function items with the same name and arity that do different things.

[ChristianGruen]

The only objection I can see is that someone might assume that if a function item has name=fn:concat and arity=2 then they can assume that the function in question is concat#2, whereas under your proposal it might, for example, be concat(?, '-', ?).

My proposal would be to preserve the function name if the result of the partial application is identical to what a named function reference returns, which is only the case for what I tried to describe as “partially applied functions without applications”, i.e., if all arguments are placeholders. In other cases, the reference to the function name must be dropped, as the resulting function item is not equivalent to the built-in function anymore.

In contrast, function-arity should always return the number of required arguments of a function item, i.e., it should return 1 for count#1, count(?), concat(?, '-'), fn($x) {}, and fn {}.

[dnovatchev]

I think we must revise the definition of "partial application" and state that f(?, ?, ...?) (all arguments substituted by ?) is not a partial application - because there is nothing "partial" in this expression - in fact it is total freedom.

Probably any such total-freedom expression must be flagged as an error. Anyway, I pity the reader who would need to count the question marks...

[dnovatchev]

My proposal would be to preserve the function name if the result of the partial application is identical to what a named function reference returns, which is only the case for what I tried to describe as “partially applied functions without applications”, i.e., if all arguments are placeholders. In other cases, the reference to the function name must be dropped, as the resulting function item is not equivalent to the built-in function anymore.

The number of actual expressions containing "“partially applied functions without applications”, i.e., if all arguments are placeholders." is likely indiscriminately close to 0.

Therefore, this new "feature" seems to be the solution to a non-existent problem.

[ChristianGruen]

The number of actual expressions containing "“partially applied functions without applications”, i.e., if all arguments are placeholders." is likely indiscriminately close to 0.

Nope; I’ve encountered this repeatedly in practice. Some people prefer to write sum(?) instead of sum#1.