“Cancel” simply cancels the edits. This flips you straight back into “read” mode on Wikipedia and Wikidata. On Wikifunctions, for existing functions, we get a “Discard Edits” confirmation dialogue first, then we are returned to the page in “read” mode. We cannot be consistent with this for a page that does not exist, but a reasonable expectation after such a dialogue prompt is that the edits are discarded and you are left on the page as it was before any edit. Anything else would imply a third option in the “Discard Edits” dialogue, which is effectively “Back”.

This seems to be a Vector (2022) problem; it does not apply to Vector legacy (2010). In legacy, the left sidebar has a Languages section with a gear icon that works correctly. In Vector 2022, this is replaced by a message linking to the non-functioning widget, so I guess that provides a good clue about what the widget should be doing. I could be wrong, but I think it is just the Universal Language Selector, in which case it should always appear (and work).

You can see some attempts to make edit summaries less mono-lingual in my more recent contributions.

Update.
The Z107 problem seems to have disappeared but the “Argument type mismatch” error persists on the Implementation page. (It is now only possible to fail to evaluate the function once on this page, since the button is disabled (and argument input boxes are not available). An associated Implementation is shown as “not associated”.)

In T306383#8201887, @gengh wrote:

This bug may prove difficult to replicate after T315448 has been fixed.

Note: I think T315233 fixed this.

I removed this:
“The Compositions that can execute successfully seem not to have the Evaluate Function box on their Implementation page (which is https://wikifunctions.beta.wmflabs.org/wiki/Z14). See, for example, https://wikifunctions.beta.wmflabs.org/wiki/Z10056.”

Comment received via Telegram:
<James_F> The page 'Z14' is actually a Z2/Persistent object encapsulating a Z4/Type representing the concept of Z14/Implementations; so Z14 has a top-level Z1K1 of 'Z2', and a second-level (within the Z2K2) Z1K1 of 'Z4'. Not sure if that explains?

Clarified here [https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Function_evaluator_call#The_normalized_type]

Should this include other special cases where there is a single element that is effectively null? For example, if a list of strings contains only {"Z1K1": "Z6", "Z6K1": ""}, does this reduce to Z13/Empty?

Nesting of Z6/Strings seems perfectly legitimate whilst a “raw string” return type does not. An explicit nesting should probably be removed during normalization but the evaluator cannot rely on this unless it performs the same reduction itself (as I imagine it should) after evaluating nested function calls.

I’m wondering whether it would make sense to think of a Z4K3/validator (function) as a constructor for validated instances of objects of the specified type. In practice, this would add an additional key into validated instances, with its value being the list of Z5/Errors (an empty list in the case of a valid object). For example, the valid positive integer represented by "2" would be the object {"Z1K1": "Z70", "Z70K1": "2", "Z70K2": []}. The unvalidated instance, on the other hand, would be a Z7/Function call to the Z70 validator/constructor function, passing "K1": "2" (and expecting type+value+errors – a validated Z70 instance – in return). This ensures that only the validator/constructor function can provide the Z70K2/errors value.

Only for a built-in Z2?

To be consistent, we might normalize a function call that should return a string, for example, as the value for a Z6K1. That is (maybe): {“Z1K1”: “Z7”, ...} normalizes to {“Z1K1”: “Z6”, “Z6K1”: {“Z1K1”: “Z7”, ...}}, just as the simple string “Wikifunctions” normalizes to {“Z1K1”: “Z6”, “Z6K1”: “Wikifunctions”}.

It seems to me that the “guidelines” envisaged are not “for external experts” but for us: “guidelines on working with external experts for the Abstract Wikipedia team and community” (or guidelines for [us] on [that]).

I wonder... Are we talking only about errors here? Or should we consider “messages” more broadly? For example, a correct evaluation could be accompanied by information about the cost of evaluation (which might be information or a warning), or the use of a deprecated or suspect object (which might be an error in some situations and not in others).

I think that makes sense. For my first option, I should have stated that the change to the referenced function’s return type would be from the more general to the more specific (e.g. from Z6/String to Z?/2-string).

Let's consider lazy evaluation.

Thanks for that, James. I may come back to this through T269182, but Happy Holidays in any event!

In T260861#6702579, @Jdforrester-WMF wrote:

In T260861#6701825, @GrounderUK wrote:

Just a thought... Do we envisage a one-to-one relationship between Z4/Type and its Z4K3/validator, or can the same validator function be reused on multiple Z4/Types (which seems to imply a supertype, but perhaps we want to keep that concept implicit for now)?

I imagine you might re-use some of the sub-functions of the validators, e.g. the validator for the type Zn for floating point numbers will have a function checking that ZnK2 is a string that represents an IEEE double-precision float (or whatever), and that would also be useful for the type Zm for complex numbers on values ZmK2 and ZmK4 or whatever.

Just a thought... Do we envisage a one-to-one relationship between Z4/Type and its Z4K3/validator, or can the same validator function be reused on multiple Z4/Types (which seems to imply a supertype, but perhaps we want to keep that concept implicit for now)?

Perhaps we should seek to minimise the selection of types. More often than not, an object's type should be the same as (or a refinement of) some other object's type. I would generally prefer to define the type by explicit reference to this other object, rather than trying to re-define it at the point of re-use. I wonder whether the same reference would also imply the type's validator? For example, the type and validator definitions of the sine and cosine functions would be the same, wouldn't they?

See also https://meta.wikimedia.org/wiki/Talk:Abstract_Wikipedia/Function_model#Make_Z7_more_uniform

The Function Model syntax requires a Z1K1/type with a value that evaluates to a Z4/Type. Including this within the "well formed" definition seems to be at odds with the proposition that "Changes to other ZObjects in the wiki cannot impact the well-formedness of a given ZObject." Where the referenced Z4/Type requires evaluation (e.g. for a Z8/Function or a Z10/List), its value depends on the function it references and upon that function's dependencies etc. I suggest that an object could be called "well formed" so long as its Z1K1 is "well formed", meaning that it could be dependent on a function that cannot, in fact, be evaluated (including one that has never existed but excluding any that cannot exist).

Do we need a separate name for inverse functions?

Okay, so here's a link...

I'm guessing that "MCR slot" is referring to Multi-Content Revisions. From https://www.mediawiki.org/wiki/Multi-Content_Revisions/Glossary:

• slot: the association of a content object (documents) with a specific role in a given revision
  • main slot: the slot with the "main" role. This is always defined for any revision, and is always a primary slot. It will be used per default in places where legacy code expects only one content object to be associated with a revision.
  • derived or virtual slots: these refer to the idea of respectively storing or generating content derived from the primary user-supplied content.