Page MenuHomePhabricator

Provide "apply" as a pre-defined, built-in function
Open, LowPublicFeature

Description

Feature summary (what you would like to be able to do and where):
I would like to request an in-built implementation for the "apply" function https://www.wikifunctions.org/view/en/Z13036. The current composition does a strange and likely wasteful hack via lists, because there is only one current (list) function which can call a function as an argument (Map function https://www.wikifunctions.org/view/en/Z873).

Secondly, it would be very useful to have a similar function ("apply2") which could apply a function that has two (or more) arguments. See below for use cases.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
The apply function already allows functions like this: https://www.wikifunctions.org/view/en/Z12875

The apply2 function would be used in functions including:

  • https://www.wikifunctions.org/view/en/Z12753
  • https://www.wikifunctions.org/view/en/Z12781
  • Sort a list according to an arbitrary comparison function. Then the sort algorithm wouldn't have to be written separately for every possible ordering metric function (e.g. alphabetic, numerical, string length, ...)
  • Test whether a list is sorted according to an arbitrary comparison function.
  • Some binary-tree evaluation/combining functions?
  • ... I'm sure my imagination is the limitation here

I'm not sure if applyN (applying a general number of arguments) would open up new cases, but I imagine it may be conceptually cleaner to write it like this, perhaps taking a function argument and a list argument to specify the list of arguments that will go into the function.

Benefits (why should this be implemented?):
*Built-in will speed up "apply"
*Apply2 will open up new types of function, as above.

*However, if there is a separate plan to allows functions to call other functions more easily, then these are probably not necessary to be inbuilt.

Event Timeline

Update: I was made aware of the in-built Reduce Function (https://www.wikifunctions.org/view/en/Z876), which enabled a hack to make apply2 (https://www.wikifunctions.org/view/en/Z13318). Unfortunately the Reduce Function is so slow that it runs out of time when checking if a three-element list is sorted (https://www.wikifunctions.org/view/en/Z13322).

So I still think some more attention is required for these in-built functions, but we are better placed than I thought.

Our general expectation is for people to use Map/Reduce, yes.

Update: I was made aware of the in-built Reduce Function (https://www.wikifunctions.org/view/en/Z876), which enabled a hack to make apply2 (https://www.wikifunctions.org/view/en/Z13318). Unfortunately the Reduce Function is so slow that it runs out of time when checking if a three-element list is sorted (https://www.wikifunctions.org/view/en/Z13322).

So I still think some more attention is required for these in-built functions, but we are better placed than I thought.

This seems like a different bug, around the scoping being mis-attached; OK if we re-purpose this?

I'm not sure what you mean by "scoping being mis-attached". But feel free to take this forward in whatever direction you think will help. I agree that Product/Design involvement is likely required.

If the slowness is because of the way we are (ab)using reduce, then it would strengthen the suggestion that we need a more direct built-in apply instead.

Jdforrester-WMF renamed this task from in-built function: apply to Provide "apply" as a pre-defined, built-in function.Apr 11 2024, 3:42 PM
Jdforrester-WMF triaged this task as Low priority.