Good with Z20K1 and Z20K2.

Z20K3 - If we have an argument, that's a function, not a function call. Remember that a Function is nothing but a declaration of the arguments and an implementation which is (in case of a composition) a function call using those declared arguments. So that's exactly what we already have syntax for in form of a Function.

In most cases, the function in Z20K3 would be:

• assume equal is a function with two arguments of the result type of the function in Z20K1
• assume curry is a function that takes a function of two arguments and a value and returns a function of one argument, with the first argument being set to the value
• so our UX might just ask for a value of the type the tested function results, let's call it VALUE
• then Z20K3 would be "curry(equal, VALUE)", and the result of that is a function that takes one argument of the right type and returns a boolean.

That's exactly what your suggested Z20K3 does, but we need no new syntax.

Wouldn't "curry(equal, VALUE)" be a function call, though? We aren't defining a function, we're invoking one. I don't feel like a user should be expected to create a full function for each tester, even if we generate most of it automatically. That feels like it would quickly clutter the system with one-use functions, raising the signal-to-noise ratio of any interface we create (because most tester functions would not have testers, themselves).

In the current work I'm doing on the front end, I'm having to construct a Z7 from the validator anyway. I think it would make more sense to provide these functions as built-ins, and allow Z20K3 to be a function call with an implied currying between the test call and the validator.

In T287202#7233373, @Lindsaykwardell wrote:

Wouldn't "curry(equal, VALUE)" be a function call, though? We aren't defining a function, we're invoking one. I don't feel like a user should be expected to create a full function for each tester, even if we generate most of it automatically. That feels like it would quickly clutter the system with one-use functions, raising the signal-to-noise ratio of any interface we create (because most tester functions would not have testers, themselves).

Yeah, that's what I'm thinking. We're asking for a function call that returns a boolean (with a special case of the first argument being the result of the other call), not just the name of a function and a value for one of the inputs. E.g. the function might be a geophys location with a tolerance (so something like positionWithin( <result>, <51N29'36.24,0W>, <10m>, <20m>, NULL) or similar for 'within 10 metres laterally and 20m longitudinally of the Royal Observatory Greenwich, ignoring height'). Just a pointer to a function and a single value wouldn't capture our needs, and having the system look up the inputs into a curry function is a bit messy.

In the current work I'm doing on the front end, I'm having to construct a Z7 from the validator anyway. I think it would make more sense to provide these functions as built-ins, and allow Z20K3 to be a function call with an implied currying between the test call and the validator.

Right.

Yeah, I would have gone and suggested to curry all these arguments, the <10m> and <20m> all into the call...

curry(equal, VALUE) is a function call, but it results in a function. So curry(equal, VALUE) is a valid Z8. But yes, there would be a lot of single use functions, indeed.

OK, OK, too much curry :)

So your suggestion would be that the Z20K3 is a function call with an implied parameter, which is basically a composition, so we could just use that as the syntax, i.e.

Z20K3: equals(<arg>, 8)

would be

Z20K3:
  Z1K1: Z7
  Z7K1: ZequalIntegers
  ZequalIntegersK1:
    Z1K1: Z18
    Z18K1: K1
  ZequalIntegersK2:
    Z1K1: ZInteger
    ZIntegerK1: 8

Or am I misunderstanding?

In T287202#7240089, @DVrandecic wrote:

So your suggestion would be that the Z20K3 is a function call with an implied parameter, which is basically a composition, so we could just use that as the syntax, i.e.

Z20K3: equals(<arg>, 8)

would be

Z20K3:
  Z1K1: Z7
  Z7K1: ZequalIntegers
  ZequalIntegersK1:
    Z1K1: Z18
    Z18K1: K1
  ZequalIntegersK2:
    Z1K1: ZInteger
    ZIntegerK1: 8

Or am I misunderstanding?

Yeah, that's it. (Or some other placeholder.)

Change 708780 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/services/function-schemata@master] data: Change model for Z20/Tester from Z7,Z8 to Z8,Z7,Z7

https://gerrit.wikimedia.org/r/708780

Change 708780 merged by jenkins-bot:

[mediawiki/services/function-schemata@master] data: Change model for Z20/Tester from Z7,Z8 to Z8,Z7,Z7

https://gerrit.wikimedia.org/r/708780

Change 709540 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/services/function-orchestrator@master] Update function-schemata sub-module to HEAD (4ffb6a0)

https://gerrit.wikimedia.org/r/709540

Change 709541 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/services/function-evaluator@master] Update function-schemata sub-module to HEAD (4ffb6a0)

https://gerrit.wikimedia.org/r/709541

Change 709542 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/WikiLambda@master] Update function-schemata sub-module to HEAD (4ffb6a0)

https://gerrit.wikimedia.org/r/709542

Change 709542 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Update function-schemata sub-module to HEAD (4ffb6a0)

https://gerrit.wikimedia.org/r/709542

Change 709540 merged by jenkins-bot:

[mediawiki/services/function-orchestrator@master] Update function-schemata sub-module to HEAD (4ffb6a0)

https://gerrit.wikimedia.org/r/709540

Change 709541 merged by jenkins-bot:

[mediawiki/services/function-evaluator@master] Update function-schemata sub-module to HEAD (4ffb6a0)

https://gerrit.wikimedia.org/r/709541

Change 711001 had a related patch set uploaded (by Jforrester; author: Lindsay Wardell):

[mediawiki/extensions/WikiLambda@master] Implement inline testers

https://gerrit.wikimedia.org/r/711001

Change 711003 had a related patch set uploaded (by Jforrester; author: Lindsay Wardell):

[mediawiki/services/function-orchestrator@master] performTest: Update to handle revised ZTester object model

https://gerrit.wikimedia.org/r/711003

Change 711003 merged by jenkins-bot:

[mediawiki/services/function-orchestrator@master] performTest: Update to handle revised ZTester object model

https://gerrit.wikimedia.org/r/711003

Change 711001 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Implement inline testers

https://gerrit.wikimedia.org/r/711001