Ours & Hippy — le blog

You rock !

Un petit détail : taper !usage pour avoir l’aide, j’ai peur que ce ne soit pas très accessible (car peu self-discoverable). Peut-être pourrais-tu en plus rajouter un petit icône de point d’interrogation à droite du champ ? De même la présence d’un lien d’aide qui indique les possibilités de syntaxe prêt de l’htmlarea serait utile pour les visiteurs de passage je pense.

Il serait aussi pertinent de réduire un peu la visibilité des commentaires re. spam en bas du message pendant la visualisation, ou de préciser leur rôle ("ils sont là pour être ignorés"), parce que ça pourrait perturber le posteur innocent (1d100 ?).

Deux petites remarques :

• à la prévisualisation :

  Warning: array_merge() : Argument #2 is not an array in /home/minh/src/blog2/blog.php on line 1370

• typo dans le texte : "retrafiquer"

Pour ce qui est de l’aide, elle est affichée à chaque recherche ne renvoyant aucun résultat. Ajouter un bouton « aide » n’apporterait pas beaucoup à mon sens car les gens préféreront essayer, se rater, et donc tomber sur l’aide, plutôt que de cliquer avant d’essayer. Au passage, si on laisse la souris au-dessus du champ, il y a une info-bulle qui dit de taper !usage.

Pour ce qui est du score, hum, j’ai rendu l’affichage plus discret. J’en ai aussi profité pour réajuster la taille des polices un peu partout sur le site (beaucoup trop petites à mon goût, mais comme je surfe avec une limite basse pour la taille des polices, je ne m’en étais pas rendu compte…). J’ai aussi ajouté des explications succintes quant au système (10 : parfait, < 0 : modéré, < -10 : ban). Ah, et j’ai refait le style des encadrés ; on se traînait les vieux de l’ancien CSS depuis un bail…

Du reste, j’ai corrigé les erreurs, et pour la doc mdown, il faudrait écrire un cheat sheet ; je le ferai si j’ai le temps, sinon je te laisserai t’en charger. Metzger a dit qu’il était partant pour aider à refaire la doc aussi, donc vous pourriez ptet faire un truc à vous deux quand même. :]

Voilà un article qui devrait certainement être posté sur le SDZ pour être lu par d'avantages de Zéros.

davantage* d'ailleurs.

Je l'ai effectivement envisagé, et j'ai prévu d'en discuter avec des validos quand j'aurai à nouveau accès à IRC, mais je pense qu'il n'est pas directement utilisable en l'état. Je pourrais en extraire la partie de vulgarisation sur le POLA et en faire un article, mais ça demande un peu de travail.

Un retour d'expérience sur l'ADA ? C'est un langage qui a fait flop mais était promis à un brillant avenir, et pour ce que j'en ai vu c'est un design plutôt raisonnable pour un langage impératif procédural orienté fiabilité (et j'ai été bien amusé par les "in", "out" et "in out" parameters, d'ailleurs ça pourrait m'inspirer un bout de billet un jour). 

Est-ce que ça a réveillé le programmeur Pascal qui sommeille au fond de toi ?

Tu sembles oublier que j’ai commencé la programmation en Turbo Pascal. :) Mais sinon bah, hum, mon expérience de l’Ada n’est pas trop mauvaise, mais loin d’être bonne.

Le principal problème que j’ai vu c’est qu’il n’y a pas de pointeurs comme en C, seulement une version très pauvre, et aucun mécanisme assez puissant et pratique pour compenser. Bien sûr, ce ne serait pas un problème si l’impératif n’était pas le paradigme dominant, mais il l’est. Après, c’est sûrement mes habitudes de programmeur C qui ressortent.

L’exemple que j’ai sous la main, là, c’est celui du parcours d’une structure simplement chaînée, dans un seul sens, où tu veux pouvoir rechaîner le nœud sur lequel tu t’arrêtes (c’est typiquement impératif et bien sûr, la solution fonctionnelle est une alternative, mais Ada se veut un langage impératif ou alors je n’ai rien compris). En C, tu peux laisser traîner un pointeur sur le pointeur membre de la structure qui te permet d’avancer, c’est sûrement la méthode la plus élégante.

En Ada, tu ne peux pas, car les pointeurs ne sont pas aliasables par défaut, et les rendre éligibles demande de modifier toutes les déclarations, parce que le type n’est pas le même (ce qui est normal). On peut voir ces contraintes comme un système similaire à celui introduit par restrict en C99, mais avec une philosophie complètement inversée : par défaut, rien n’est aliasable et il faut explicitement déclarer les choses pour qu’elles le soient (en vérité, les tableaux en Ada étant dissociés des pointeurs, le problème adressé n’est pas le même, mais c’est une bonne analogie). Cela paraît intéressant : pour mettre en rapport ce qui n’a rien avoir, c’est un peu le principe du moindre privilège. :) Mais en pratique, c’est foireux, parce que si en C tu peux abandonner ton droit à l’aliasing temporairement dans un contexte local, l’inverse n’est bien entendu pas possible, donc utiliser des pointeurs sur objets possiblement confondus est une grande décision en Ada et relève de la conception et non de l’implémentation. Tu ne peux pas dire, « cet algo-ci, je l’implémente avec des pointeurs aliasés parce que c’est cool ». Cela rend leur usage marginal.

La solution en Ada dans le cas simple est de tout récrire en récursif terminal et d’utiliser des paramètres in out :

procedure Supprimer(P: in out Nœud; X: Valeur) is
begin
   if P.Val = X then
      P := P.Suiv;
      -- Dans la vie, il faudrait libérer le nœud aussi.
   else
      Supprimer(P.Suiv);
   end if;
end;

C’est meugnon comme tout, faut avouer, mais ça manque de flexibilité, et dans des cas plus complexes, ça pêche. Typiquement, cela se gâte quand on veut faire du réutilisable, car le design récursif se marie bien avec les fonctions d’ordre supérieur. En C, je peux transformer mon précédent algo en une fonction qui renvoie deux pointeurs : un vers l’objet lui-même et un vers le pointeur qui le référence. En Ada, en voulant imiter, le mieux que je pourrais faire est de renvoyer un pointeur vers le nœud précédent. Mais là, on se heurte à un problème d’homogénéité : les racines n’ont pas de prédécesseur. Du coup, on se retrouve à devoir traiter à part des cas marginaux et cela se répercute vite à travers tout le code, ce qui duplique le code utile et généralement rend les choses dégueux.

Alors bien sûr, on se dit que le fonctionnel c’est cool, que l’on devrait prendre exemple et passer des fonctions. Qu’à cela ne tienne, il y a des génériques en Ada ! En plus, on ne se tape pas les perfs douteuses des appels indirects, w00t. Mais la syntaxe est tellement lourde que cela n’en vaut guère la peine, et enchaîner les génériques devient vite un calvaire. Ma règle du doigt est que quand la quantité de code nécessaire à la déclaration des génériques et de duplication du typage qu’il engendre approche dangereusement de celle de code utile, il faut faire sans. J’ai déjà réussi à écrire du code générique avec les routines communes factorisées qui prenait plus de place que son équivalent avec duplication du code utile mais sans génériques…

Le second point qui me chagrine beaucoup en Ada, du moins avec GNAT, qui, il faut bien se le dire, semble être la seule implémentation viable en existence, est que les exceptions, très très présentes un peu partout dans le langage, sont horriblement lentes. Je me rappelle de mon premier TP où les profs annonçaient une heure pour faire tourner le programme, et où, un jour avant le rendu, je me suis aperçu qu’en remplaçant les exceptions par des retours de fonction comme en C, je passais de trois heures à huit minutes. Fais le calcul par toi-même, cela fait presque 22 fois plus rapide !

Bien sûr, quand j’ai dit ça aux profs, ils ont tenté de relativiser la chose, de trouver des excuses à la pauvre bête, mais il ne faut pas se voiler la face, on aurait dit ça de Ruby, ça aurait fait rigoler tout le monde.

Pour la liste, je ne suis pas sûr que ce que tu décris soit spécifiquement impératif : n’est-ce pas la même chose avec le List.tl de caml, qui renvoie un pointeur vers la queue de la liste, et crée donc un alias si on a gardé la liste initiale accessible ?
Si c’est bien ce dont tu parles, je pense que la solution est effectivement de rendre les pointeurs d’une linked-list aliasables, parce que le fait de "pointer un noeud interne comme sous-liste de ses successeurs" est une opération naturelle, quel que soit le paradigme.

Pour les génériques, effectivement quand j’ai vu le design du truc je me suis un peu méfié. Ça fait un peu polymorphisme pour les pauvres, et si tu les utilises sur de grosses fonctions peu timing-critiques tu perds rapidement en taille du code les avantages que tu gagnes en performances. Après il y a aussi des compilos SML qui spécialisent comme ça, donc ça doit avoir son intérêt dans certains cas, mais au moins au niveau de la syntaxe il vaut mieux du vrai polymorphisme. C’était sans doute trop expérimental au moment du design d’ADA, mais maintenant le polymorphisme à la ML c’est bien connu, et surtout si on fait pas d’inférence ça ajoute pas beaucoup de complexité.

C’est vrai aussi que la lourdeur de la syntaxe d’une feature joue beaucoup sur son intérêt dans la pratique. C’est assez malheureux parce que ça joue souvent en défaveur de la compréhensibilité en poussant les designers à choisir les syntaxes les plus concises mais pas forcément les plus explicites. Une solution pourrait être de régulièrement prévoir deux syntaxes, une courte pour les petits bouts de code, et une longue pour les gros. Ça fait un peu usine à gaz, mais en pratique pas mal de languages ont fait ça pour certaines features seulement, de manière assez ad hoc, et au final un peu d’uniformité pourrait être bénéfique (en C if/else et l’opérateur conditionnel ternaire, en C# les méthodes anonymes et les lambda-expressions, en Caml begin/end et les parenthèses, etc.).

Et tu as vu un peu les features de modularité du langage ? Il me semble que dans le monde impératif c’est un plus récents relativement mainstream à s’occuper vraiment de la modularité sans obligatoirement faire de POO. Ça change du C ? :-`

NB : Si si pour le Pascal, c’était une référence — pas assez explicite on dirait.

J’ai un peu été vite en besogne et je me suis trop branlé sur le parallèle avec restrict du coup j’ai un peu oublié la réalité et le cas « évident » que tu mentionnes parce que hum, c’était… trop évident. Mais en fait non, d’après ma formulation, donc je vais détailler.

En fait, un Ada, les objets dynamiques (dynamiquement alloués) sont aliasables mais les autres non, par défaut. En plus de ça, un pointeur par défaut ne peut contenir que l’adresse d’un objet dynamique. Bref, ça demande deux déclarations pour avoir un pointeur comme en C :

• déclarer le pointeur comme universel (pouvant pointer sur n’importe quoi) ;
• et déclarer l’objet comme étant aliasable.

Genre, si t’as un type :

type Liste;
type Acces_Liste is access Liste;
type Liste is record
   X: Valeur;
   Suiv: Acces_Liste;
end record;

Bah, tu peux aliaser des Acces_Liste entre eux pourvu qu’ils soient dynamiquement alloués, mais par contre, si dans une fonction tu déclares :

L: Liste;

Bah un pointeur de type Acces_Liste ne peut pas pointer sur L. Faudrait rajouter aliased à la déclaration d’L et rajouter all à celle d’Acces_Liste.

Puis, imagine tu balances maintenant :

type Acces_Acces_Liste is access Acces_Liste;

Bah ça en gros, t’en fais rien, parce que ça ne peut aliaser que les pointeurs de pointeurs dynamiquement alloués, soit rien d’utile. Et même si tu rajoutes all, bah ça ne pourra toujours pas pointer sur le champ Suiv de la structure Liste parce que faudrait y rajouter aliased. Tak tak.

Et c’est de ce dernier point dont je parlais, pouvoir pointer sur le champ Suiv avec un pointeur de pointeur. En Ada tu peux oublier.

Donc pour me corriger parce que dire de la merde sur mon propre blog c’est pas cool : les pointeurs en Ada ne s’aliasent pas par défaut avec des objets statiques.

À part ça, question modularité, les packages, c’est sympa, mais c’est un peu lourd à l’usage. Les génériques sur des packages, c’est acceptable parce que tu dilues la déclaration lourde dans plus de fonctions importées au final. Les règles de portée sont sympas, mais on est au final loin de la flexibilité qu’offre les templates du C++ (ou alors faudrait bourrer des tonnes de code dupliqué, ce qui est horrible) ou des foncteurs Caml (de ce que j’en connais).

On reproche au C le fait de devoir dupliquer les signatures des fonctions en déclaration/définition, bah l’Ada reprend ça (et à mon avis, en pire, avec les génériques en plus, du coup tu en arrives à déclarer trois ou quatre fois la même signature), alors qu’honnêtement, ya pas de raison (en fait si, on pourrait avoir besoin du fichier d’interface avec une lib pré-compilée mais chai pas, ils avaient qu’à dire que les interfaces dans ce cas doivent être pré-compilées aussi, bref) ; le C utilise des #include donc les déclarations ne sont pas couplées avec le code d’implémentation, mais en Ada, tout est couplé alors pourquoi diable doit-on tout déclarer en double ?

Par rapport au C, le gros plus niveau modularité, c’est les génériques, mais comme je le disais, la syntaxe est trop lourde ; j’aime bien le concept mais il faudrait moins avoir à déclarer le moindre ptit truc. En C++, tout le monde râle que c’est crade que les paramètres en entrée de templates bah ça peut être n’importe quoi, donc tu peux avoir un class A dont après tu appelles des méthodes un peu n’importe comment. Mais en Ada, il faut tout déclarer, et je trouve que ça devient vite très relou. En gros, si ton package A accepte un paramètre générique T qui lui-même est un package, et que disons tu veux que T expose f et g comme fonctions ; bah en Ada, tu déclares un package générique B qui prend deux paramètres génériques f et g avec les bonnes signatures, puis tu dis à A d’accepter T une instance de B, et au moment d’instancier A, tu le fais avec une instance de B à laquelle t’auras refourguer les fonctions qui vont bien (tu pourrais directement spécifier f et g comme paramètres génériques d’A, mais je fais exprès de prendre un design factorisé pour que tu vois comment ça fait lourd quand tu veux faire « propre »). Maintenant, là où ça fait mal au cul, c’est que tu ne peux pas dire « mon package C implémente l’interface offerte par B donc hop op pop je file C à A ». Non, faut que dans C tu recopies toutes les signatures demandées par B, que tu les implémentes bien sûr, puis que tu crées ton instance de B et que tu lui donnes les fonctions qui vont bien (ça tu peux le faire comme un sous-package de C pour que ce soit réutilisable, à la rigueur), et que tu refiles ça à A. Ça ne paraît pas choquant comme ça mais si tu as C, D et E qui implémentent tous B (ce qui est le but avec un tel design) bah je te laisse imaginer da pain. Du coup ça s’auto-mutile quoi ; ça a les moyens de faire des choses propres, mais comme tu te retrouves comme un con à recopier à droite et à gauche ton typage ultra-verbeux bah tu fais rien de ta vie ; t’as pondu des centaines de lignes de code avec du vide.

Ça je pense que c’est parce qu’Ada n’a pas de sous-typage au niveau des packages, tu dois écrire les projections toi-même au lieu de le laisser le faire (éventuellement en le lui demandant explicitement). Les modules ML ont ça; ils ont même mieux, un sous-typage structurel, tu peux dire "toute signature qui implémente f et g avec ces types là" et t’as pas besoin de passer par une interface B intermédiaire, ni de préciser dans les déclarations de C, D et E qu’elles satisfont bien B comme on le fait en sous-typage nominal (qui a aussi ses avantages) comme dans la plupart des langages OO. Mais la théorie derrière est tout de suite plus compliquée et ça existait pas trop au début d’ADA (même s’ils auraient pu le rajouter après, s’ils ont mis de la POO ils doivent bien avoir du sous-typage).

PS : j’ai l’impression que les commentaires ont un peu dévié du billet initial. C’est gênant ? Je suis prêt à essayer la prochaine fois de trouver le point de déviation et envoyer plutôt un mail à ce moment là. Sinon, une pratique courante chez certains bloggueurs c’est, quand ils veulent répondre de manière circonstanciée et intéressante, de faire un billet dédié à ça en citant le ou les commentaires instigateurs. Tu devrais l’envisager, ça te ferait plus de billets à peu de frais, et sans compromis non plus sur la qualité (même si omg il a dit un truc faux, il doit en être tout traumatisé).

Merci pour le petit compliment sur EnsiZero !

Au contraire bluestorm, évitez de poursuivre ce genre de discussions intéressantes en privé.

Qu'est-ce que ça t'apporte d'avoir à t'occuper de l'UTF-8 toi même ? J'avoue que j'ai un peu de mal à voir l'intérêt.

En tant qu'administrateur système, c'est pas le genre de truc que tu serais ammené à faire tous les jours si ? C'est juste pour t'amuser ?

Hum, bah en fait, c’est pas le fait de devoir faire plus de choses qui me plait, c’est sûr. :D C’est plus que configurer directement les logiciels, au lieu d’avoir une surcouche, est une bonne chose, à mon avis ; déjà parce que tu peux lire la doc upstream, et que quand tu changes quelque chose au niveau de la configuration du programme même, tu n’as pas la mauvaise surprise de découvrir qu’un autre bout du système (la surcouche) te parasite tes efforts à vouloir imposer sa loi.

Souvent, quand il y a une option globale, comme sous Gentoo, et que pour telle ou telle raison, elle ne marche pas comme tu veux (et cela m’est arrivé, aux débuts du support UTF-8 sous Gentoo) bah tu te retrouves à lire le code spécifique à ta distro qui effectue les réglages concernés. Généralement ce code n’est documenté nulle part, et forcément la doc upstream ne t’aide pas.

En tout cas si tu changes d'avis, un français vient de finir (il y a quelques heures) de porter emerge vers netbsd : http://monsieurp.boulz.org/pub/img/gsoc/gentoo-netbsd-emerge.png D'autres images sont disponibles dans le sous-dossier en question. Pas mal de boulot post-gsoc est envisagé apparement, comme tous les gsoc j'imagine.

Sinon, est-ce que ça ne veut pas dire que la surcouche est mal faite ? Les patchs changeaient quoi ? Normalement ça devrait juste demander à l'app le support utf-8 non ? Et puis c'est pas le "début du support utf-8" tous les jours. Il doit aussi y avoir l'intérêt de limiter les modifications : ça permet de limiter le temps passé à faire de la maintenance, je suppose.

Un GSoC ? Pour Gentoo ? Je n’ai pas entendu parler de ça chez NetBSD… c’est étrange un projet pour porter quelque chose vers NetBSD qui ne soit pas un projet NetBSD ! Pour l’instant je me débrouille, avec pkgsrc, donc je ne compte pas tellement changer.

Le souci d’un package manager externe comme emerge (je n’ai pas regardé en détails mais je suppose) c’est que l’intégration avec le base system ne sera probablement pas terrible. L’exemple classique est le suivant : imagine, j’ai X.org dans base, et j’installe un package qui nécessite X. Clairement, dans la majorité des cas, je ne veux pas installer un second serveur X. Et pour cela, il faut que le package manager se mette d’accord avec mon base system.

Sinon, comme je l’ai dit sur IRC, ce n’est pas une question de patches mais plutôt d’avoir un autre point de configuration permettant de changer les mêmes paramètres, et les deux pourraient entrer en conflit. Après, l’expérience joue, c’est certain ; quand j’ai commencé ma première configuration d’UTF-8 sous Gentoo, je débutais complètement en admin et du coup, instinctivement, je me reposais sur les réglagles automatiques de ma distro, et quand ça ne marchait pas, je me disais « ah bah Gentoo c’est pas encore prêt pour UTF-8 ». Il y avait une grosse variable UNICODE à mettre à yes dans le script de configuration du démarrage, le rc.conf. Celle-ci entraînait à son tour plein de petites modifications derrière mon dos. Et j’aurais préféré savoir qu’il fallait que j’appelle telle commande pour avoir une console système en UTF-8, telle autre pour avoir X en UTF-8, et telle autre encore pour avoir une application précise en UTF-8. Le problème d’avoir une variable globale magique comme celle-là, c’est que tu ne sais jamais trop d’où peuvent venir les problèmes : tu ne sais pas si telle ou telle étape a bien été effectuée, ou si elle n’a pas été faite de travers, ni d’ailleurs dans quel bout du système la configuration s’est faite.

De manière plus générale, je ne suis pas contre automatiser les tâches, mais je pense qu’il vaut mieux donner des exemples à l’utilisateur, bien commentés, qu’il pourra adapter à ses besoins, plutôt qu’un script tout prêt qui est censé couvrir tous les cas (donc compliqué) mais qui au final ne peut vraissemblablement pas tout prévoir, ce qui est normal en vérité, dans un environnement hétérogène constitué de plein de composants provenant de différentes personnes. Il y a quelques conventions, comme les locales, qu’il ne fait pas de mal de spécifier globalement, mais essayer de satisfaire à tous les caprices de tous les programmes que l’utilisateur pourrait vouloir installer est une bataille perdue d’avance. Dès lors, imagine, j’ai mis que je voulais de l’Unicode partout, dans la configuration centrale de ma distro. Si Emacs n’est pas en UTF-8, est-ce parce que ma distro a mal fait son boulot ou est-ce qu’il faut que je configure Emacs moi-même. La réponse souvent est pire : on est entre les deux, ma distro a fait un bout, et il faut que je devine ce qu’il me reste à faire. C’est pour cela que je suis contre ce genre de surcouche.

Ya pas d'secret un bon codeur
C'est avant tout un prédateur
Il chass' la meilleure conception
Les bonnes factorisations
Les otaries les loups-garous
Et mêm' la peau des vieux gurus

Utilisons l'typage
On va faire un carnage
Les aut' l'ont pas : dommage
Ils ont que du garbage !

Pour pas crever ya pas d'astuce
Faut pas prendre un langag' qui suce
Les types algébriqu' c'est mortel
Mon gars faut faire du fonctionnel !
Mon compilo il est sans fautes
Eux tout c'qui zont c'est des Segfaults

Utilisons l'typage
On va faire un carnage
Les aut' l'ont pas : dommage
Ils ont que du garbage !

Mais si tu veux ya plus basique
C'est chiant c'est l'interface graphique
Les laids qui codent en POO
Ils font que ça ils  restent au zoo
Leurs patterns c'est d'la rigolade
Tak Tak j'retourne à mes monades !

Excellent cette petite poésie 1

Owi, trop bon §!1111!!!§§§

je suis tout aussi intéressé par des commentaires généraux sur la réaction : avez-vous trouvé ça intéressant ? Trop détaillé ? Pas assez détaillé ?

A mon avis, il serait plus intéressant d’approfondir le sujet plus que de paraphraser le paper comme tu dis, avec éventuellement une courte bibliographie (le problème des papers c’est quand même la taille énorme des bibliographies). Après ça dépend le public que tu vises, si tu préfères faire de la vulgarisation ou de l’approfondissement, en tout cas là j’ai bof envie de lire l’article (en plus c’est du SML, bouh).

Un problème aussi c’est la longueur du coup ; franchement le format de blog de rz0 actuel rend la lecture de l’article quelque peu indigeste (à quand l’export PDF ?). A mon avis, il vaudrait mieux publier ce genre d’articles en plusieurs parties, ne serait-ce que pour tenir le lecteur en haleine et le laisser méditer sur le sujet.

Enfin bon voilà, moi je serais plus pour des articles relevant quelques détails un peu flous ou qui ont des liens avec des trucs intéressant sur le paper (la lecture du paper serait un pré-requis).

Je ne veux pas que la lecture du paper soit un prérequis; mon but ce n’est pas de commenter de manière pertinente un paper d’info, en espérant rajouter quelque chose de valeur derrière l’auteur (ce serait assez vain étant donné que je ne connais essentiellement pas les domaines concernés), mais plutôt de préparer à la lecture en indiquant au lecteur les choses intéressantes, les choses que j’ai trouvées incompréhensible mais dont on peut se passer (afin qu’il ne croit pas qu’il faut tout comprendre), et les choses qu’on peut facilement rater si on ne fait pas assez attention.

Dans l’absolu, c’est plus pensé pour être un teaser qu’un post-commentaire. Pour cet article je me rends compte effectivement que j’ai fait trop de paraphrase, mais c’est parce qu’il est vraiment très elliptique et que ça demande donc un effort assez important de le lire sans préparation. Je n’ai pas abordé toutes les notions de l’article originel, et mon billet ne peut pas remplacer sa lecture, mais je pense que ça le rend accessible à un public plus large.

Par contre tu as totalement raison sur la longueur : c’est trop long. J’ai beaucoup de mal à estimer au départ la longueur que je vais produire, et j’ai tendance à être assez verbeux, donc ça fait vite des trucs très gros. Ça me demande aussi pas mal de travail. Je pense essayer de découper en plusieurs billets ce genre de chose dans le futur (j’ai déjà commencé pour des billets en préparation), et on va réfléchir aux méthodes pour faciliter la navigation (hier déjà rz0 a ajouté des boutons "billet précédent / suivant" pour faciliter la navigation, il est très réactif sur ce genre de choses).

Merci pour l’idée de l’export PDF. Je n’y ai pas pensé, je vais faire des essais, même si je ne suis pas sûr que ce soit pratique au final.

Je me sens stupide quand je lis tes articles :p

Hum, bah côté technique, c’est du Caml, on n’en fait pas à l’Ensimag, et si tu n’en as pas fait avant, forcément, quand on n’a pas l’habitude, c’est pas évident. Par contre, côté théorique, toute la première partie de l’article, jusqu’aux fonctions SR, c’est de la redite de nos cours de TL (S1) et calculabilité (S2).

Enfin, personnellement, je trouve ça pas trop mal comme article de vulgarisation sur un domaine qui ne m’est pas complètement familier (mais demeure connexe à mes intérêts). Si tu as un avis plus précis, Bastien, sur ce qui t’a plu ou pas, ou sur l’organisation générale, n’hésite pas à nous en faire part. :)

J'ai une petite question à propos de "l'enrobage mathématique" présenté en début d'article. Je préviens tout de suite, même si j'ai une licence en maths, j'en ai surtout une en info, et les maths c'est pas spécialement mon trip. Donc désolé si la question est conne.

On prend une fonction de A dans B, sauf qu'elle peut échouer, donc "en fait elle est de A dans (B + {⊥})". Et pour une fonction A -> B -> C, ça veut dire qu'on a une fonction de A dans (B + {⊥}), puis une fonction de (B + {⊥}) dans (C + {⊥}) ? On peut donc "passer la divergence" comme un paramètre ? J'ai un peu du mal avec la notion. Plus tard tu considères que "tout retourne ⊥ si A retourne ⊥", mais est-ce qu'on est passé par la fonction qui va de B dans C ?

J'ai l'impression que ce sont des points qui sont "logiques" pour toi mais il me manque des éléments là.

Alors déjà pour le traitement de (A -> B -> C), c’est curryfié, donc c’est exactement équivalent à (A -> (B -> C)). De là on peut sans doute appliquer la définition et obtenir une réponse claire, mais il faut y penser et tu as raison de demander à expliciter ce point là.

Donc : [A -> B -> C], c’est [A -> (B -> C)] soit A -> ({⊥} + [B -> C]), c’est-à-dire A -> ({⊥} + (B -> {⊥} + C)). En gros, tu commences par donner l’argument de type A, et là soit ça plante (⊥), soit tu as une fonction partielle [B -> C] à laquelle tu donnes l’argument de type B. On considère donc la fonction qui prend du B en paramètre seulement dans le cas où ça n’a pas planté.

L’idée c’est que ⊥ n’est pas une valeur. Ça ne correspond pas à un objet qui existe dans notre langage, puisque c’est au contraire l’absence de résultat. Si une fonction termine, elle renvoie une valeur (qu’on dénote par un élément de B) mais sinon elle ne termine pas (par exemple elle boucle à l’infini). Ça n’a donc pas de sens de "passer ⊥ en paramètre" puisque ce n’est pas une valeur du langage : si tu as essayé de faire un calcul qui n’a pas terminé, mathématiquement tu as "⊥", mais informatiquement tu as un plantage et tu ne peux pas "continuer" : passer des paramètres, etc.

C’est donc là qu’on rejoint la notion de "⊥ donne tout le temps ⊥" : une fois que tu atteins ⊥ mathématiquement, le calcul a "échoué" et il reste comme ça. Si f x échoue, alors g (f x) échoue, quelle que soit g : on commence par vouloir f x et c’est l’échec. C’est une autre définition des langages stricts.

On peut aussi consolider l’enrobage avec plus d’enrobage : il y a une idée implicite dans ce que je dis, que je peux formaliser. Je parle de la sémantique (l’objet mathématique correspondant au code informatique) des fonctions, mais pas de celle des applications de fonction. Si f est une expression qui désigne une fonction, et x qui désigne une valeur, quel est l’objet mathématique [f x] correspondant à l’application de f à z ?

• si [f] = ⊥, c’est ⊥
• sinon c’est [f]([x]) : [f] est une fonction partielle, donc le résultat peut encore être ⊥