Wikipédia abstraite/Mises à jour/2021-01-21

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Abstract Wikipedia/Updates/2021-01-21 and the translation is 98% complete.
Other languages:
English • ‎français • ‎українська • ‎日本語 • ‎한국어
716-newspaper.svg Mises à jour de la Wikipédia abstraite Translate

liste de diffusion de la Wikipédia abstraite Wikipédia abstraite sur IRC Wikipédia abstraite sur Telegram Wikipédia abstraite sur Twitter Wikipédia abstraite sur Facebook Wikipédia abstraite sur Youtube site web de la Wikipédia abstraite Translate

Le bulletin de cette semaine est un peu plus technique que les autres.
Avant d’en venir au contenu principal, un rappel : la phase de soumission de concept de logo est actuellement ouverte ! Six propositions ont déjà été faites et méritent beaucoup d’aller les voir. J’espère voir plus de propositions arriver, la date butoir de soumission est le 16 février.

Le modèle de fonction formel, tel qu’il est actuellement écrit, suppose que la totalité du modèle de fonction est déjà mise en œuvre. En particulier, il dépend de types génériques, ce qui signifie qu’un type est paramétré, habituellement par un autre type.

Peut-on donner un exemple de type paramétrique ? Considérons le type pour les listes.

Une liste est une suite ordonnée d’éléments. Quel est le type de ces éléments ? Ce pourrait être n’importe lequel ! Il y a plein d’opérations qui peuvent être réalisées sur les listes sans avoir besoin de connaitre quel est le type des éléments dans la liste. On peut prendre le premier éléments de la liste, inverser l’ordre des éléments de la liste, prendre un sur deux des éléments successifs de la liste ou beaucoup d’autres opérations.

Quel est le type de l’élément retourné par la fonction qui sort le premier élément d’une telle liste ? Vous ne pouvez pas le savoir. Puisque les éléments de la liste peuvent être de n’importe quel type, le type retourné par la fonction sortant le premier éléments peut aussi être de n’importe quel type.

Dès lors, au lieu d’avoir un seul type appelé « liste », vous pouvez avec des types appelés, par exemple, « liste de chaînes », « liste de nombres » ou « liste de booléens ». Ou même de façon plus compliquée, « liste de listes de chaînes ». Vous pourriez avoir une liste de tout type d’éléments, ou plusieurs sortes de listes en même temps. Maintenant si vous avez une fonction qui retourne le premier élément d’une « liste de chaînes », vous savez que le type de retour de cette fonction sera toujours une chaîne. Vous avez davantage de sureté du typage et vos outils d’écriture de code peuvent vous fournir un meilleur guidage lors de l’écriture des fonctions et des appels de fonctions, puisque savez que cela doit être une chaîne. Il est également plus facile d’écrire les fonctions puisque vous n’avez pas à vérifier les cas où peuvent survenir des éléments d’autres types.

Mais d’un autre côté, nous avons soudainement besoin de beaucoup plus de nouveaux types.

En théorie, un nombre infini de types spécialisés. Et pour chacun de ces types, nous aurions besoin de toutes les fonctions spécialisées pour traiter ce type, ce qui conduit à une explosion du nombre de fonctions. Ceci serait un cauchemar de maintenance, car il y aurait tellement de code devant être vérifié et écrit alors que tout ceci est très minimal.

Afin d’éviter cela, nous pourrions écrire des fonctions qui créent le type et les fonctions dont nous avons besoin et qui prennent le type des éléments de la liste dans un de leurs paramètres. Donc au lieu d’avoir un type « liste de chaînes », nous aurions une fonction, appelons-la list(string), qui n’a qu’un seul paramètre et que vous pouvez appeler list(string) et qui résulterait, à la volée, en un type qui est une liste dont les éléments sont des chaînes. Ou vous pouvez appeler list(integer) pour obtenir une liste dont les éléments sont des entiers.

La même chose est vraie pour les fonctions : au lieu d’avoir une fonction « premier » pour que cela ne fonctionne que sur une liste de chaînes et retourne une chaîne, nous aurions une fonction prenant le type « chaîne » en paramètre, retournant une fonction qui travaille sur une liste de chaînes et qui retourne une chaîne. Au lieu d’avoir à écrire une fonction « premier » pour chaque type de liste, nous n’aurions à écrire qu’une fonction qui crée ces fonctions et qui les retourne quand nécessaire.

Il existe également des situations où la dimension des entrées typées que vous avez besoin d’opérer est limitée par un nombre, plutôt que seulement ou en même temps que le type.

Dans un exemple plus compliqué, si nous avions une méthode pour réaliser un produit matriciel, le nombre de colonnes dans la première matrice entrée doit correspondre au nombre de lignes dans la seconde. Alors, au lieu de juste prendre un type pour créer la matrice (par exemple, un nombre en virgule flottante), notre fonction de premier niveau prendrait également deux entiers en paramètres pour les nombres de lignes et de colonnes. Nous appellerions alors cette méthode avec matrix(float, 4, 3).

De façon similaire, les informations de géolocalisation sur Terre sont généralement relayées par deux dimensions angulaires, et de façon facultative, une information d’altitude ; là vous devez avoir tuple(float, 2) pour les premières informations et tuple(float, 3) pour la dernière.

La façon exacte dont la communauté Wikifonctions modélisera le type position sera décidée par ses membres — en décidant d’un type, ils pourront vouloir spécifier explicitement le corps planétaire, son système géodésique, la précision dans chaque dimension ou d’autres données également. Nous devons nous assurer de fournir la flexibilité aux éditeurs qui leur permet de représenter les choses dont ils ont besoin ou qu’ils veulent. Notez que les types courants, tels que les coordonnées sur Terre, seront probablement créées comme des types nommés sur le wiki, mais des structures peuvent toujours être créées à la volée également.

Cette idée a de nombreux noms et réalisations concrètes dans différents langages de programmation, tels que les modèles, les concepts, le polymorphisme paramétrique, les fonctions ou types de données génériques, etc. Pour nos finalités, nous appellons ceci des génériques et leur mise en œuvre est actuellement planifiée dans la phase ζ (zêta).

Maintenant, un point essentiel est que le modèle de fonctions, tel qu’il est écrit actuellement, dépend fortement des génériques. Mais avant que ceux-ci soient en place, nous ne pouvons pas réellement les utiliser. Nous sommes donc en quelque sorte dans les limbes, où le modèle de fonctions que nous mettons en œuvre en ce moment même n’est encore spécifié nulle part ; et au lieu de cela, nous ajustons à la volée en nous basant sur l’état actuel de la mise en œuvre tout en sachant où nous voulons éventuellement aboutir.

Afin de soutenir cela, nous publions un modèle de fonctions pré-génériques explicite. Notez que ceci ne décrit pas le modèle tel qu’il est juste maintenant, mais c’est le modèle que nous allons mettre en œuvre essentiellement vers la fin de la phase γ (gamma) et qui est donc plus immédiatement utile que le modèle de fonction final que nous avons actuellement décrit sur le wiki. L’idée est que lorsque nous aborderons la prise en charge des génériques, nous passerons du modèle pré-générique ou au modèle de fonction complet. Comments and suggestions on the pre-generic function model and the plan presented here are, as always, very welcome.

Articles de fond sur Wikipédia :

Et souvenez-vous du concours de propositions de concept de logo !