Wikifunctions:Status updates/2024-03-28

◀

Wikifunctions Status updates

▶

Creating tests is now much easier!

Automatically filled Test case for the to lowercase function

Test cases are a crucial part of defining what functions mean and ensuring all Implementations stick to that definition. And yet, the creation of a good test has been somewhat challenging:

1. Go to the Function and click on the plus in the box of Test cases
2. Select the Function call you want to test, using search
3. Enter the arguments for the call
4. Select the Function to check the result, using search
5. Enter the arguments for the check

The idea is that the Test works by running the call you have built in steps 2 and 3, and then check the result with the Function built in steps 4 and 5. If the latter check returns true, the test has passed. If it returns false, the test has failed.

Selecting the right Function to check the result isn’t always straightforward: you need to be aware of the result Type of the Function and must either search for, or simply know, the right Function to check the resulting value.

A few weeks ago, we extended Types with the ability to know their equality function, i.e. what is the Function, if it exists, for testing whether two values of that Type are equal or not.

With this week’s release, the process of creating Test cases has been considerably simplified: you click on the plus button, and both the Function for testing and the Function for checking the result are automatically selected and filled-in for you. You can still go and change it – for example, if the pre-selected checking Function is not appropriate, and you need something else. But you can now just click on plus, enter all relevant arguments, and publish the Test case.

Thanks to Geno who was the engineer behind this Quality of Life improvement! We hope that this will make writing Test cases faster for all, and especially that it will be simpler and easier for newer community members to understand how to do the right thing.

Recent Changes in the software

A big piece of work we've been doing this week has been to create a properly-documented API designed for gadgets, tools, and third parties to call to run Wikifunctions. Expect details soon! Alongside that, we've made some feature improvements to make using Wikifunctions easier.

First, as mentioned above, when creating a new Test case, we now auto-fill the test call to the target Function being tested and, where possible, the validator's call to the returned Type's equality function (T358214).

Second, when prompted to pick a Type or a Natural language, we now use a new feature of the Codex UX library to give suggested options rather than expecting you to know the name of one already (T350037). For Types, if you click into the field it will suggest string and boolean; for Natural languages, it will suggest the "United Nations Six" languages. In the future, this may support more Types, and allow on-wiki control of what options are presented; please discuss this on-wiki if you have ideas.

In terms of bugs, we fixed an issue where we always expanded new items in lists, regardless of its Type (T359576). We fixed the special page listing Objects to use the primary label if it's available, rather than an alias (T358805). We corrected the logic that decided whether to show a 'chip' in the page's header for the Object label and sub-title for its Type, using the relevant language chain for each label (T360000).

All Wikimedia-deployed code is using the latest version of the Codex UX library, v1.3.5, as of this week. Though we do not believe the library upgrade will have any user-visible changes in our use on Wikifunctions, please comment on the Project chat or file a Phabricator task if you spot an issue. We have also upgraded the Ace library (from 1.14.0 to 1.32.7) that provides the editor and syntax highlighter when writing code implementations (which is also used when editing site JS/CSS pages, user scripts, and gadgets). Similarly, the upgrade should not make any significant changes, but please do highlight to us if you notice any issues.

Upcoming Volunteer’s Corner on April 8th

The next Volunteer’s Corner will be on 8 April 2024 at 22:30-23:30 UTC. We scheduled it to a different time, to accommodate different people than usual. The timing is for now a one-off. We are still working on the timing in order to accommodate as many people as possible, and are considering a rotating timing, possibly having three different times each quarter. We appreciate feedback and will be taking note of attendance.

The agenda of the Volunteer’s Corner is as usual:

1. Off-the-record time to ask questions
2. Recording starts
3. Update on the project (also shared online afterwards)
4. Time for questions
5. Work together on a function
6. Time for questions
7. Recording ends
8. Off-the-record time to ask questions

We are looking forward to meeting you! Let us know if you would like to attend but the times so far didn’t work out and which times would work for you.

Guest editor next week

I’m taking a week off, but we will have a guest editor next week!

Function of the Week: NOR (Z10231)

I have been looking forward to writing about the NOR function (Wikipedia article, Wikifunctions function) for a while. In fact, that’s why I previously introduced the NOT and the OR functions.

Nor is the negation of the or function. Just like the or function, nor is a binary Boolean function: it takes two arguments of type Boolean and returns one. Since or returns true if either of the arguments is true, nor returns true only if neither one nor the other argument is true.

Just as the other binary Boolean functions, Nor has four Test cases (corresponding to Nor's truth table):

1. True NOR true is false
2. True NOR false is false
3. False NOR true is false
4. False NOR false is true

These tests are complete in Wikifunctions, meaning that every possible combination of inputs is covered with the tests. We won’t have that luxury for many other Types!

So, what’s so special about NOR that makes me excited about it? The interesting thing about NOR is that any other Boolean function can be implemented by using just the NOR function. No matter how many arguments, all you need is the NOR function, possibly several times, and nothing else. Of the sixteen binary Boolean functions, only two have this special property.

I am not saying that it’s a good idea to only use NOR, but it is possible! We could have implementation for all our Boolean functions using only NOR, which can be an interesting educational resource. The same is true for NAND (not-and). For example, the NOT function can be implemented by using NOR with the same value in both arguments.

The NOR function has four Implementations:

1. In JavaScript, combining the language's ! (not) and || (or) operators
2. In Python, combining the not and or keywords
3. One composition using NOT and OR
4. Another composition using two if functions

It can be an interesting exercise to think through the last composition and understand why it results in the NOR function.

I always thought that the name of the function, “nor”, came from combining the words “not” and “or”, similar to how the “nand” function is named for combining “not” and “and”, but it seems I got my direction wrong: nor simply comes from the English word “nor”, and was then reinterpreted as “not or” in order to be a pattern for “nand”.