Abstract Wikipedia/Updates/2023-11-16

◀

Abstract Wikipedia Updates

▶

What types next?

We currently support two types: strings and Booleans. Our next big step for expanding the capabilities of Wikifunctions is by introducing more types. We are working hard to get all the pieces in place: we have previously talked about serialization to make types work seamlessly with programming languages, and renderers and parsers to improve the experience when using them.

Data can take many different types for many different domains

The first new type we expect to open for the community is a type for lists. This will not only allow for many new functions that are not possible yet (such as breaking a sentence into words), but also to simplify existing implementations such as this test for mutation in Breton or this (overly simple) check if a letter is a vowel, implementing a function we created collaboratively in this week’s Volunteer Corner.

But, as asked by Cool314 on the Project Chat, what should be the next types that the community would like to see? They also suggest starting with the list type, which, as said, is on the way. They say to follow with integers, and if that means non-negative integers or counting numbers, I would be totally on-board. But what would be next?

The list of suggested functions requiring new types also strongly suggests counting numbers. After that we find suggestions talking about more complicated numbers, such as negative numbers, floating-point numbers, fractions; then also bytes and specific-length vectors of bytes; colors; years, months, and dates; and others.

One thing we need to take into account is to go for simpler types first: for example, a calendar day could be built from a counting number and a month, or it could be built from two counting numbers – but one way or the other, we would need counting numbers first.

Another question is whether we prefer to have our types to be built from simpler elements, or whether we prefer more complex types. To give a very simple example, there are many different ways to represent integers, two of which would be:

1. An integer could be represented by an object with a single key, a single string that starts with an optional “-” and ends with a whole number, i.e. a list of digits with no leading zeros
2. An integer could be represented by an object with two keys, one being the sign (which is one of negative, positive, or none), and the other a counting number, which we would have previously defined as a type

Then there is also the question of which string would represent which value, a question that needs to be answered for each individual type. For numbers one straightforward solution is to take the string representation of the numbers in Hindu-Arabic numerals, but one could also consider binary, hexadecimal, or even base64 encodings, potentially reducing storage space. I think that the potential to more easily understand a JSON representation would beat the small storage gain.

Finally, what limits, if any, should we put on these values? Frequently, programming languages have a numerical limit for their 'number' type of the range from 0 to 4.2 billion (2^^32) or 0 to 18 quintillion (2^^64). Should we add a limit like this as well, or should we expect function writers to work with any possible input?

Note that this does not mean that we only will be able to deal with Hindu-Arabic numerals: with parsers and renderers we will be able to display numbers appropriately for a given language, remaining fully translated for whichever language and locale users are using. We might not necessarily have that feature available immediately when introducing new types, but we will be working on enabling them soon.

Let us hear and discuss what you think (or even come up with a process for us to follow, based on the types you are suggesting). What are the types you are looking forward to?

Recent changes to Wikifunctions software

From now on, we will try to give a quick summary with each update of what work you can see as it rolls out to Wikifunctions.

In terms of big items, following the completion of "General Availability" last week, we've been primarily working on the software to better support types (as discussed above; T343469). On the back-end this has meant infrastructure support for applying custom code to convert from Wikifunction types to native types and back (T297509), and on the front-end we've been working on using lists as inputs and outputs of functions, coming soon (T326301). We've also been working with several volunteers to understand how we can improve the on-boarding experience (T285509); thank you to everyone who has taken part.

Our general improvements have included progress on being more consistent in using proper, specific, translatable errors consistently throughout the system (T321113), and researching if it's possible to make any further simple improvements to picking a type or object (T345547).

As minor fixes, we now use a different title on the creation page depending on whether you're making a function, implementation, test case, or type, rather than just say 'object' (T350673 and T341847). We also fixed the view of aliases to be one bulleted list of several items, not several lists of just one (T345404).

You can browse the full list of deployed changes for the MediaWiki front-end for Wikifunctions. We didn't deploy any back-end service changes this week.

No newsletter next week

Due to holidays, we will be skipping next week’s newsletter. Expect to hear from us again after Thanksgiving!