Wikipédia abstraite/Mises à jour/2023-11-16

◀

Actualités de la Wikipédia abstraite

▶

Quels prochains types ?

Nous avons actuellement deux types de données : les chaînes de caractères et les booléens. Notre prochaine grande étape pour étendre les capacités de Wikifonctions est d'introduire plus de types. Nous travaillons dur pour mettre toutes les pièces en place : nous avons déjà parlé de la sérialisation pour faire fonctionner les types de manière transparente avec les langages de programmation et les renderers et les parsers pour améliorer l'expérience d'utilisation.

Les données peuvent prendre de nombreux types différents pour de nombreux domaines différents

Le premier nouveau type que nous nous prévoyons d'ouvrir à la communauté est un type pour les listes. Cela permettra non seulement de nombreuses nouvelles fonctions qui ne sont pas encore possibles (comme la division d'une phrase en mots), mais aussi de simplifier les implémentations existantes telles que ce test pour la mutation en breton ou ceci (trop simple) vérifier si une lettre est une voyelle, en mettant en œuvre une fonction que nous avons créée en collaboration dans Volunteer Corner de cette semaine.

Mais, comme le demande Cool314 sur le Project Chat, quels types devraient être les prochains que la communauté voudrait voir ? Il suggère également de commencer par le type de liste, qui, comme déjà dit, est en route. Il dit de continuer avec les nombres entiers, et si cela signifie des nombres entiers non négatifs ou des entiers, je serais totalement à bord. Mais qu'est-ce qui viendrait ensuite ?

La liste des fonctions suggérées nécessitant de nouveaux types suggère également fortement les nombres entiers. Ensuite, nous trouvons des suggestions qui parlent de nombres plus compliqués, tels que les nombres négatifs, les nombres à points flottants, les fractions ; puis aussi des octets et des vecteurs de longueur spécifique des octets ; couleurs ; années, mois et dates ; etc.

Une chose que nous devons prendre en compte est de commencer par les types plus simples : par exemple, un jour calendaire pourrait être construit à partir d'un nombre de comptage et d'un mois, ou il pourrait être construite à partir de deux nombres de comptage - mais d'une manière ou d'une autre, nous aurions besoin de compter les nombres d'abord.

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!