Wikifunctions:Status updates/2024-02-22

Wikifunctions Status updates

Updating the function model

A few weeks ago we started an update of the function model. The page was set up early in the project and captured the original plan for the function model, and was written prescriptively and aspirationally. The actual implementation diverged from it in a number of ways. Some of these divergences might be still aspirational, whereas others have evolved (e.g. Benjamin arrays) and we have no intention to go back.

The page as it was before the updates was basically not useful, as it represented neither the current status nor where we want to end up. We took the time to update it from beginning to end, with the goal of representing the function model as it is right now. It has now been updated to the current state where appropriate, and aspirational content has been removed.

This is one step in improving our documentation. We think that the function model is useful but not as useful as it could be: one set of feedback we got was that it is hard to read and understand. We heard that and are thinking about creating more documentation that is more accessible and can support more paths for a diverse audience to find their way to understanding Wikifunctions deeper if they want to do so.

Feedback and comments are welcome.

Recent changes in the software

After last week's "Fix-It" drive, this week we returned to work on the focus features as shared two weeks ago, as well as some smaller bug fixes. We continued our work on better support for Types, with work on the way that user input will be transformed into a value and vice versa, which we hope to demonstrate soon, and then use in reality so that the next Type can be created and used, on the way to interacting with Wikidata lexemes and items.

We made a change to how the load of the software works for readers, which means that we only load a small part of the Codex library before putting the language control button on the page, rather than demanding the whole library needed for rendering and interacting with Objects, which comes in a few tenths of a second later. This should make browsing Wikifunctions slightly faster for all readers and editors, especially for non-Object pages. Our thanks to the Design System team for their work to make this possible.

We re-wrote our code handling Wikifunctions Objects on the front-end, as it could sometimes flake out and provide a broken user experience on the site; we renamed and better documented the methods, and added a number of tests to demonstrate the previously-broken, now-fixed behaviours (T352799).

We fixed two bugs seen in production; one is an error check when processing function calls in the API (T357691), and the other is to fallback to English when trying to change the display text of links to ZIDs and the language isn't known (T357702). Spurred on by this, we also fixed the fall-back code when trying to access a non-existent page with a non-English user language; previously this would try to redirect you to the page called "Main Page" as translated in your language, but now it will correctly send you to the actual main page in your language.

We updated the credits file for the MediaWiki part of the software, which adds Winston Sung (welcomed last week).

Function of the Week: Negation

Negation (not (Z10216)) is a unary Boolean function. A unary function is one with a single argument. Boolean functions are functions where all arguments are of type Boolean, i.e. they can be either true or false, and the return type is also Boolean.

Negation takes one Boolean value and returns the other: if you ask for the negation of true you get false, and if you ask for the negation of false you get true. This is also how the composition is implemented: if the value is true, return false, else true. This is one pattern I really like seeing with one composition: a composition that expresses what the function means in an almost declarative way, without regards to how efficient the implementation is. I am still thinking of a good name for these — maybe definitional compositions? The usefulness of these definitional compositions is that they serve both to explain what the function does, and also to give a high confidence implementation to test the more efficient implementations against.

Beyond the composition, there are three further implementations:

In Python, using the keyword not
In JavaScript, using the ! operator
Another one in JavaScript using the ! operator, using a different syntax

I would recommend that as a community we come up with a JavaScript syntax guideline that would suggest to only have one or the other JavaScript implementation.

One interesting thing about Negation is that because the input types can only have a closed, small set of different values, we can actually create a complete set of tests, which test every possible input. In this case, in fact, there are only two possible values: true and false. Accordingly we have two tests: one that makes sure that the negation of true is false, and one for the opposite, that the negation of false is true.

You can read much more about Negation on Wikipedia.