Re: Update, 26 May 2026
Yes, a general “negative filter” would be helpful, allowing the omission of population and GDP statistics from country items, for example. I have it planned as part of a broader post-fetch statement-filter approach and there my tentative conclusion was that each filter should be either positive or negative across all dimensions, just for usability. Otherwise, we risk building a query language. For the limited dimensions of a fetch like Z6820, however, I think we might manage a usable solution that allows each dimension to be specified either positively or negatively. I don’t see any real use case for language exclusions, but I imagine that most fetches should actually exclude either labels or statements. Similarly, I see no case for excluding qualifiers, whereas excluding references would be the norm. That said, if we bring statement identifiers into scope, I can envisage cases where we would initially filter reduced statements and then use the identifiers to fetch the expanded statements. For example, abstract:Q762 asserts that Q215486 is a notable work by Leonardo da Vinci, so we are first interested in the existence of Q762•P800•Q215486 (undeprecated), which happens to have no references, and then in Q215486•P170•Q762 which has two references, which happen to be project imports (P143) and therefore not, in themselves, legitimate references. (So the hypothetical function-call result is a call-to-action: add-reference-to-identified-statement.)

This now succeeds in v2.

This is perhaps overtaken by T420333. Or perhaps that became a duplicate after its re-framing. Either way, I don’t think we need both.

Please note T383842#11572688.

In Abstract Wikipedia, text that is not in the target language should be accompanied by a reference to the alternative language, for example: as a link, as text or as a footnote. Without a link from the Natural language to its Wikidata item, none of these options is viable. Z29749 is one of the most widely used functions on Abstract Wikipedia (called from over 400 pages but prefixing the Latin script language tag (when required) produces unsatisfactory rendered content in any language. The same approach is also adopted by the Z11 display function, Z21583, leading to unsatisfactory results for any embedded function that returns Monolingual text, when the result is not in the requested language.

In T421468#11892314, @DMartin-WMF wrote:

…The point is that Wikifunctions can't make guarantees about the form (reference or literal) in which an instance will come to an implementation…

Mentioned here https://abstract.wikipedia.org/wiki/Talk:Q916

Stepping back, what happens to abstract.wikipedia.com links in the AW content, when delivered to the language edition?

Boldly re-assigning to the more appropriate backlog. Revert at will!

It’s a separate feature, but tagging the Persistent object with the contributor list would allow ordinary searches to be restricted to objects with contributions from particular contributors.

I think this duplicates T419561 or, at least, it’s a subset.

In T423325#11826039, @Jdforrester-WMF wrote:

This sounds like it's low user value, and would be yet another breakage of the function model (an implcitly-optional key).

Maybe that too… but when the default function is returned, it seems not to be a problem. The problem is that, for example, a ZReference for Z1002 does not have a language tag == "en", so the code can never return anything other than the default (whether as function, reference, or quoted reference).

Temporary fix, as before: disconnected Z14403.

Appears to have regressed.

Would Z0 work? I’d be reluctant to use anything that might be an actual ZID, but I’m guessing it’s inert anyway. Maybe Z8?

In T419931#11770111, @cmassaro wrote:

The issue here is that the function identity is ultimately being given as a Z6/String. I see how this worked in v1, but it's technically a violation of the function model (one which we are now enforcing).

There are a few ways we can handle this. I have a little hack that works: https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/624 . However, the behavior is ill-defined. Maybe we can accept Z6/Strings as the identities of anonymous functions, but it would be better if the string being given as the function identity looked like a ZID (i.e., instead of abcd, something like Z123456789). What are your thoughts?

In T420021#11773726, @cmassaro wrote:

(it works in my local env, at least)

Still failing from Wikifunctions.org but the error is now rendered:

In T421391#11766706, @cmassaro wrote:

AH. Hahaha, so Z801.Z14K1 makes no sense because Z801 is a Function. If I call it with Z901 as of HEAD, all is well.

Oops! Sorry about that. Z14 is definitely not currently working for any key reference, however: nice stack trace.

It looks like this is no longer limited to test-case editing. I changed Z32879 at 15:15 yesterday and the previous version of the implementation is still being used for new function calls and only works correctly when editing. This is the reverse of the original problem and much more disruptive.

Now that we have functions restricted by return type in the front end and the type-checking in user land is facilitated by v2 improvements, subject to T421506, would you like to consider resolving this task under T413837?

Now that we can have arbitrary function calls in a test case, and can check intermediate results with Z854, I think we can call this closed, thank you.

This may be related. I had to apply an emergency fix to Z11s display function, which has only a Python implementation, which was:

def Z21583(Z21583K1, Z21583K2):
	if Z21583K1.Z11K1 == Z21583K2:
		return Z21583K1.Z11K2
	else:
		return f"({Z21583K1.Z11K1.Z60K1}) {Z21583K1.Z11K2}"

The Z11 in K1 contains a ZReference whereas the Z60 in K2 has a language tag in Z60K1. The initial condition is now always False and attempting to access the Z60K1 of the ZReference naturally fails. The emergency fix simply returns the Z11K2 unconditionally, which is misleading. The alternative is to return the Z11K1.Z9K1 as well (in all cases), which is generally unhelpful.

More detail will be useful but we should also cater for new contributors (in particular) by providing a call-to-action for any error result.

I wouldn’t object to Option 1 as a matter of principle, but it would seem to be considerably more expensive than the “expensive” type comparison in Option 3. It’s virtually free at the point of executing the guard, but that’s a bit late when the whole of Q30 has been shipped across along with the invalid argument.

It would be better for the string value to be returned, since that is the object’s Z6K1 when normalised. If this is objected to, the error should be Key not found, since the particular representation lacks a key with the specified reference. But see my first sentence and T389487.

With v2, Z1K1 now succeeds but Z6K1 still fails:

It has been simplewiki’s policy for twenty years now, so I wouldn’t expect it to be an issue.

You mean that when quoting a function call we somehow get both the literal function-call object as data (quoted) and, separately, the scope of its construction, to which its argument references refer? Sounds more like the best of both worlds than a “happy medium” - a limited and specialised closure.

No, if v2 isn’t supposed to be fixing these functions then there’s no issue, only opportunity!

Thanks. It’s not a huge issue but it seems to be happening “all the time”, just so you know.

In T419833#11720381, @cmassaro wrote:

[…snip…]

Z30928 will therefore need to be changed. I suggest something like

Z30928 = function ( quotedFunctionCall ) {
    return builtinValueByKey(
        'K1',
        builtinGetError( builtinUnquote( quotedFunctionCall ) )
    );
}

i.e., the argument should be a Z99 wrapping a Z7, and the argument to Z853 should be the result of Z899 called on the quoted Z7.

Quite possibly. Please see T420225.

In T373607#10855000, @WrenFalcon wrote:

Ran into this today. See e.g. the test cases for Z12427/is prime - for several of the "is not prime" tests (for a specific example, test "2147483647^2 is not prime", implementation "is prime (Python)"), the test displays as "Passed" for a number of implementations, but clicking on the details reveals that the test had an error: "Reached time limit in evaluator".

I believe that the reason why it shows as passed is because it passes Z24/void to Z844/Boolean equality, and the built-in implementation of Z844 considers Z24/void to be equivalent to Z42/false - see test case Z24790. I would consider changing this behavior in the built-in implementation or changing the definition of "passed" for a test to not include evaluations with errors.

In T417631#11700432, @Jdforrester-WMF wrote:

I believe that this is now fixed with v2 (though note we're returning Z516/Argument value errors not Z506/Argument type mismatches).

Referenced in Wikifunctions:Community portal#Tasks listed by users

I’ve disconnected the “preferred” JavaScript implementation (Z14403) for now.

In T411565#11700434, @Jdforrester-WMF wrote:

In T411565#11691766, @GrounderUK wrote:

Thanks for the update.

Are similar manifestations also expected to be fixed?

Yes, possibly; we should evaluate each issue on its own though! Thank you for highlighting.

I’ll be checking the tickets I’ve raised, as and when time allows.

For example, error returned for non-Boolean argument (Z31987) succeeds with only one of ten implementations

This now passed for three of the ten (in edit mode to not get the cached results). Not sure if that's good enough?

Z903 still fails to return Z1K1 or Z6K1 for a string, but we no longer get an explicit Z507/evaluation failure. I’m not sure if fixing T389487 is in scope, but the error now is:

Looking good now, thanks!

Thanks for the update.

Most critically, I would say it is at the interface between functions. A called function benefits from static guarantees provided by the composition itself, but if the interface is not strictly typed on both sides, that guarantee can fail at runtime, with downstream consequences that are difficult to trace (or even identify as having occurred), especially when the interface is encapsulated within another function.

I’ve raised a couple of tickets relating to type-guarantee failures: T411565 and T417631. These guarantees are currently costly to enforce in user functions. See, for example apply two-argument function: validated arguments (Z31684), with this test.

Nice! There’s some problem with the function signature, for which I’ve filed a ticket. I’ve also used the function in:

• reverse untyped list, Composition: accumulator (Z31639)
• append element, Composition: orchestration only (Z31632)

Sounds like fun! I’ve recently added prepend reversed first list to second list (Z31580) as a “primitive” reversal function. It scales reasonably well, but can we look forward to significant improvement with V2 tail-call optimisation? One thing I noticed is that the type for the result list is de-referenced to a full type object on recursion, which seems undesirable.

Any chance of an update on this one, please? Is the time taken for the system to fix itself predictable?

Please see the Project Chat topic List typing still annoying, which references this ticket.

In T407932#11577095, @99of9 wrote:

In T407932#11575188, @GrounderUK wrote:

I’m not sure how we could apply an absence of conversion to a returned value, other than by returning a map or using ZObject(), ZReference() or ZPair(). Given that we now have those options, we might consider converting numbers by default, according to their native type, I suppose, but if the function’s return type is explicit, it should be respected.

An example of where we need close-to-raw returned values is https://www.wikifunctions.org/view/en/Z26982 (equal rational with numerator length). The crucial requirement is that we separately return each of the keys of the object we are returning, and they don't get messed with during the conversion from code. Can we already do this with ZObject()?

In T407932#11572205, @99of9 wrote:

• Does this only apply to inputs? To outputs? To only some inputs? Etc.

Some of the other answers may depend on the decision here, so I'll answer it first. I suppose the ultra-flexible ideal would be to selectively apply to whichever inputs and outputs the implementation creator chooses. My specific proposal is for all inputs and all outputs, because I expect that will be easier to design, because this will only be needed in rare circumstances, because it does allow code to access everything, and because those who use it will be willing to go the extra mile on raw-processing other inputs/outputs if they need it for one. I'm open to seeing different designs before weighing in on whether I expect they would work.

I don’t object to “void” but it would seem more helpful, in general, to surface the explicit error. Without actually designing the user experience, I’d say we will always want to be able to see both parts of the response. I’m wary of shuffling things around according to the state of the response, but a stronger signal that there is an error might be achieved by just showing a link to the relevant error type. For consistency, a no-error link or text might be shown for a successful evaluation.

In T389183#11528747, @cmassaro wrote:

Ah, I see. I think we will be phasing that kind of validation out, so it is not (or will not be, in the near future) by design that a type would need to be validated.

In T411947#11509627, @99of9 wrote:

I don't mind changing it, but it appears to be passing all implementations at the moment?

As expected, some test cases were failing when revisited in edit mode and passing when an empty list replaced the call to nullary void (Z26199) for the arguments to emulate Wikidata statement object (Z23723).

It seems I was repeating myself, sorry.

In T414181#11506909, @Jdforrester-WMF wrote:

The problem here is that the orchestrator entirely ignores the on-wiki version of pre-defined persistent objects (ZID < 10k). I'm not sure we want to re-open that performance issue?

Maybe not, but we do want Z828 to do what it is designed to do. It works for Z60s, so I don’t think it’s a problem with all pre-defined Persistent objects, just Types.

I think it is the same issue, but it should already be covered under T405411 anyway, if not. Original report:

Trying non-builtin implementations of echo, the Python error is:

A quoted reference still fails to reach Python or JavaScript code.

Another example is (!) Z1K1.Z1K1.Z9K1 is "Z7" (Z16887). It was connected in error over a year ago but, as luck would have it, never became the preferred implementation (or perhaps implementation selection counts failures correctly).

Thanks. We don’t get to see the detail, but we do get a well-formed Unit, as far as I can tell.

In T351770#11474702, @99of9 wrote:

I agree with your final recommendations.

Finally… Thanks!

Adding example function calls (because we can, thanks). Correctly echoing is no kind of error.

• Z560 echoing Unit-typed object
• echoing Z24/void

I suspect this is a side-effect of T409229.

This is now working, as confirmed by Reference from ZID string (Z29102). Happy for it to be closed, but I expect you’ll want to link it to the change etc.

I had a slightly different manifestation recently. this was failing in edit mode. It passed as soon as it was published but went back to failing again after visiting the function page, where it showed as passing… it may be that the 22:44 edit on the test case caused the reversion.

In T407207#11446809, @DSmit-WMF wrote:

@GrounderUK Do you think its ok with the message for now? If so, close it?

I haven’t been so actively distracted recently, so I’ve yet to see the message on failure. I’ll re-open if I should happen to get a silent failure in the future. Thank you.

I’ve removed Russian from the configuration. If the occasional failures in wikilambda_fetch are logged, I think this can be closed.

In T405839#11451405, @GrounderUK wrote:

Testing…

Looking good, thanks. Closing per request.