Wikifunctions:Status updates/2026-10-17

Wikifunctions Status updates

Changes in evaluator representations

As of next Wednesday, we will make a slight change to the intermediate representation of function arguments in the evaluator. These objects will no longer be ingested as pure normal-form ZObjects; instead, Lists will be represented as JSON arrays. To be more precise, they will be represented as Benjamin arrays, the type-safe array representation used in canonical form and elsewhere in WikiLambda. Thus, instead of

{
  "Z1K1": {
    "Z1K1": { "Z1K1": "Z9", "Z9K1": "Z7" },
    "Z7K1": { "Z1K1": "Z9", "Z9K1": "Z881" },
    "Z881K1": { "Z1K1": "Z9", "Z9K1": "Z6" }
  },
  "K1": { "Z1K1": "Z6", "Z6K1": "hayyy" },
  "K2": {
    "Z1K1": {
      "Z1K1": { "Z1K1": "Z9", "Z9K1": "Z7" },
      "Z7K1": { "Z1K1": "Z9", "Z9K1": "Z881" },
      "Z881K1": { "Z1K1": "Z9", "Z9K1": "Z6" }
    }
  }
}

the executors will now see

[
  { "Z1K1": "Z9", "Z9K1": "Z6" },
  { "Z1K1": "Z6", "Z6K1": "hayyy" }
]

As you can guess, this is being done to reduce object size: a normal-form list represents the list's type once per list value, which gets expensive very fast and causes explosive memory usage in the executors (just imagine what a nested list would look like!). With the new approach, the type will be represented only once per list.

So, what do you need to do? If you haven't been working with type converter functions, nothing. If your type converter functions don't convert types with embedded lists, also nothing! This change only affects you if you're working on type converter functions that manipulate types with internal list values. For now, this change only affects input objects (function arguments), so the focus is on type converters to code. Your converters will now need to be able to handle the new format instead of the old one (or in addition to it, if you'd like to avoid breakages in the interim!). We may make a similar change to function return values in future, but for now, type converters from code are unaffected.

To make this a bit easier, we are also enabling you to call type_convert_to_code() and type_convert_from_code() (in JS: typeConvertToCode and typeConvertFromCode) directly in your code implementations and type converter code! By using these functions, you'll get forward- and backward-compatible behavior. A major limitation, though, is that these functions currently work only for built-in types and combinations thereof: only Z6/String, Z9/Reference, Z40/Boolean, Z21/Void, Z881()/List, Z882()/Pair, and Z883()/Map types are supported in these functions. Thus, you couldn't use type_convert_to_code() on a Z881(Z13518)/List of Natural numbers, but you could use it on a Z881(Z6)/List of Strings or even a Z881(Z882(Z6, Z40))/List of Pairs of String and Boolean. This represents a step toward an eventual future where you can define type converters in terms of each other, allowing for type converter code reuse!

Recent Changes in the software

This week, we made a number of improvements. In the details dialog on Wikifunctions, we refreshed the time-ago labels so they no longer go stale (T440533), and we removed a confusing message about provenance in the Test case results section (T440537). We also fixed an issue where Object labels that looked like ZIDs displayed incorrectly and, in some cases, could not be published (T437013).

In addition, the “About” quick editing of labels/aliases/descriptions no longer overwrites other editors’ changes made after you opened the page (T436793), and rollback links for edits on Objects work again (T395219). We also fixed “Copy result link” so that it copies the result link rather than the content of the current inputs (T433744).

On Abstract Wikipedia, because some result links are too long for browsers to handle, we no longer offer the “Copy result link” option in those cases (T439078), and we improved the highlight that connects a fragment to the preview (T439109).

Finally, Igbo and Dagbani Wikipedias have had integration enabled, following Malayalam. Communities can turn integration on through Community Configuration, and nothing is added automatically: whether and which articles to integrate is always the local community's decision. You can find more information in the newsletter two weeks ago.

Fresh Functions weekly: 119 new Functions

This week we had 119 new functions. Here is an incomplete list of functions with implementations and passing tests to get a taste of what functions have been created. Thanks everybody for contributing!

A complete list of all functions sorted by when they were created is available.