Wikipédia abstraite/Mises à jour/2022-04-28

◀

Actualités de la Wikipédia abstraite

▶

Pré-requis pour le code des Wikifonctions

Une fois les Wikifonctions lancées, nous prévoyons actuellement de prendre en charge l'implémentation de fonctions dans deux langages de programmation, Python et JavaScript. Mais malheureusement, cela ne signifie pas que tout le code disponible, écrit en Python ou JavaScript, sera facilement disponible pour être copié et utilisé dans les fonctions Wiki. Le code doit répondre à certains pré-requis. Dans la newsletter d'aujourd'hui, nous discuterons de ces pré-requis et de ce que vous pouvez faire pour préparer le code que vous souhaitez rendre disponible via les Wikifonctions.

Tout d’abord, il doit être légal d'importer le code. Conformément au résultat de la discussion de la communauté, le code sera publié sous la licence Apache-2. Si vous avez écrit le code vous-même, ou si vous en détenez les droits, vous êtes libre de le publier dans les Wikifonctions. Si vous prenez le code d’un projet open source existant, vous devez vous assurer qu’il se trouve sous une licence compatible.

Ensuite, le code doit être « fonctionnel ». Cela signifie que, pour une entrée donnée, le code doit toujours renvoyer la même sortie. En particulier, cela rend un certain nombre de classes de fonctions indisponibles :

• Le résultat doit être déterminé par l’entrée et n’avoir aucune composante aléatoire. Cela signifie que nous ne pouvons pas avoir une fonction qui simule le lancement de dés, qui renvoie un GUID nouvellement créé ou des résultats aléatoires similaires. Un élément aléatoire briserait notre stratégie de mise en cache, en particulier la possibilité de mémoriser tout appel de fonction et de le remplacer par son résultat s’il est disponible.
• Le résultat de la fonction ne peut pas dépendre implicitement de l’heure, de la date actuelle ou de l’emplacement de l'utilisateur. Cela signifie que nous ne pouvons pas avoir une fonction qui renvoie le jour actuel de la semaine. Si nous voulons nous appuyer sur un tel contexte, nous devons le rendre explicite en tant qu’argument de la fonction. Une fonction telle que « quelle est la hauteur du soleil ici en ce moment ? » devra être reformulée ainsi « quelle est la hauteur du soleil pour un endroit et une heure donnés ? » et prendre le lieu et l’heure comme arguments.
• Un appel de fonction ne peut pas avoir d’effets secondaires intentionnels. Il ne doit pas y avoir d’appel de fonction susceptible de provoquer un changement spécifique dans le monde, par ex. un appel de fonction qui ordonne à un robot de démarrer une certaine routine ou qui allume une lumière. Oui, un appel de fonction aura toujours un effet sur le monde (il peut entraîner la modification des caches, il utilisera des ressources informatiques et transformera de l’électricité en chaleur), mais ceux-ci sont accessoires et peuvent changer à l’avenir. Quelqu’un peut écrire un système qui utilise les résultats des fonctions Wiki pour contrôler ses robots ou appareils, mais le contrôle réel serait implémenté dans ce système, pas dans les Wikifonctions.
• Une fonction ne peut pas avoir un état caché modifiable par un appel de fonction. Ceci est une conséquence du point précédent. Cela signifie, par exemple, que nous ne pouvons pas avoir une fonction qui comptabilise la fréquence à laquelle elle a été appelée et renvoie ce nombre.
• Cela signifie aussi qu’il ne peut pas y avoir d’appel de fonction qui modifie un article Wikipédia ou modifie un élément Wikidata. La modification d’une fonction, ou d’une implémentation de fonction, peut éventuellement modifier le contenu d’un article sur Wikipédia (c’est-à-dire une fois que nous autoriserons l’appel des fonctions Wikifonctions à partir d'articles sur Wikipédia), mais appeler une fonction sur Wikifonctions ne provoquera pas le changement de contenu d’un article.
• Une fonction ne peut pas appeler le Web ou l’Internet. Aucune requête HTTP ou mécanisme similaire ne sera autorisé au lancement. Toutes les ressources ou données qu’une fonction souhaite utiliser doivent être fournies en tant qu’arguments.
• Au départ, les fonctions ne pourront pas accéder aux données des projets Wikimedia. Nous prévoyons d'étendre les Wikifonctions dans une première étape après le lancement pour permettre l'accès aux éléments et aux lexèmes dans Wikidata et plus tard aux métadonnées des fichiers multimédias sur Commons.
• Les fonctions ne peuvent pas stocker ou charger des fichiers dans un système de fichiers persistant, ni lire ou écrire dans une base de données persistante. Ils ne peuvent accéder à aucun autre réseau ou appareil.

Certains de ces cas d'utilisation pourront être abordés après le lancement (par exemple, afin de permettre des résultats aléatoires ou d'utiliser des arguments implicites pour des fonctions telles que « quelle est l'heure actuelle ? »), mais ceux-ci nécessiteront une planification minutieuse, une discussion et, au final, des modifications apportées au système.

Voici d'autres restrictions que les Wikifonctions auront initialement :

• Python et JavaScript disposent tous deux d’un vaste écosystème de bibliothèques tierces. Au départ, il ne sera possible d’accéder qu’à la bibliothèque standard Python et aux objets standard JavaScript. Nous prévoyons d’autoriser ultérieurement un processus pour ajouter d’autres bibliothèques et les rendre accessibles à partir d’une implémentation.
• It will initially not be possible to call another Wikifunctions function from a code implementation (only from compositions). We plan to allow that, although this might initially be restricted to cases where the called function also has an implementation in the same programming language.
• Initially, only certain types will have built-in serialization/deserialization logic (i.e., code that maps between the ZObject representation and in-memory objects for each programming language). These types are Boolean, string, List, Map (becomes a dict in Python or a Map in JS), and Nothing (None in Python, null in JS). For every other type, native code will work directly with the respective native JSON object at first. We are working on a design to allow the community to add serialization and deserialization for more types.
• This also means that there is no real support for 'objects' in the sense of object-oriented languages. The interface with Wikifunctions will be a function call, not a call to the method of an object that can rely on internal state. There is also no information hiding in objects. Every value in Wikifunctions must be entirely serializable and deserializable. Values are immutable, which also is at odds with how objects are commonly designed and used in practice in many object-oriented contexts.
• Initially, we won’t have a built-in mechanism to support dispatch or a type hierarchy.

We are already planning to add more programming languages, but they will also have similar restrictions. Both JavaScript and Python, as well as many other languages, allow top-level functions to be defined. For other languages, such as Java or Smalltalk, we would need to define a slightly different pattern in order to interact with the functional interface that Wikifunctions provides. Whenever we add a language, the process will involve a design step in which we will discuss the appropriate mappings. We also plan to document how further programming languages can be added so that the effort becomes predictable.

This post has no examples and no how-to, but rather describes the requirements for implementations. In the following weeks, we will follow up with one or more posts that examine a few patterns and examples on how code from libraries could be reused within Wikifunctions.

Thanks to Mahir256 for providing comments on earlier drafts of this newsletter.