Discussion :

[monstre]

Bonjour à tous,
Je m'intéresse depuis peu à la programmation fonctionnelle et plus particulièrement au langage Haskell. Or, si je comprends à peu près le fonctionnement du monade IO, sa raison d'être demeure toujours un mystère. Quel est l'intérêt de mettre ainsi les effets de bord (side effects) en quarantaine? Pour un programmeur familier avec l'approche impérative, il est difficile de voir une telle restriction comme un avantage, surtout lorsqu'elle se manifeste à travers d'absconses constructions mathématiques. Or, si l'on suppose que les créateurs du langage n'en auraient pas limiter l'expressivité sans raison, cet avantage, réel ou imaginaire, doit bien exister. Ma question est fort simple : quel est-il?

Merci d'avance de vos réponses.

[gorgonite]

as-tu lu cela ?
http://gorgonite.developpez.com/livr.../?page=io#LVII

[monstre]

as-tu lu cela ?
http://gorgonite.developpez.com/livr.../?page=io#LVII

J'ai lu la version anglaise, qui n'avait de gentle que le nom, et ma question demeure entière.

[Jedai]

Dans un langage purement fonctionnel, on peut raisonner sur le programme et faire des démonstrations qui ne sont pas possible avec un langage impératif, grâce à la transparence référentielle. Les Entrée/Sortie sont typiquement un phénomène "à effet de bord" dans le paradigme traditionnel, donc utiliser des fonctions pour les décrire viole la transparence référentielle. Pour rester un pur langage fonctionnel, il faut donc interdire les Entrées/Sorties.... Sauf que sans I/O un programme ne sert à rien, c'est pourquoi Haskell avait besoin d'un mécanisme pour modéliser l'I/O tout en la séparant du reste du programme (sans contaminer celui-ci).
Il a choisi la monade I/O, qui se contente si on la prend littéralement de décrire une suite d'action. Pour une description des alternatives envisagées (et parfois implémentées) et des différentes visions sémantiques qu'on peut avoir de la monade IO, je te conseille "Tackling the Awkward Squad", un excellent papier sur l'I/O, l'interfaçage avec le C, la programmation concurrente et les exceptions avec Haskell.
Toute personne vraiment intéressé par l'aspect théorique d'Haskell devrait lire cet article à mon humble avis.

--
Jedaï

[InOCamlWeTrust]

Je ne dirais pas celà : c'est une explication que beaucoup de personnes donnent, mais je pense que ce n'est pas la bonne.

Les monades ne sont pas exclusivement réservées aux opérations d'entrée/sortie : en réalité, elles sont un concept beaucoup plus général que celà. On pourrait imaginer un système d'opérations d'entré/sortie sans monades, mais on aurait énormément de mal à programmer avec dans un langage paresseux (j'y viens).

Il m'a fallu beaucoup de temps pour comprendre ça, et ce n'est expliqué nulle part, bien que ce soit extrêmement simple. Si tu comprends ce qui suit, tu auras tout compris sur l'intérêt des monades. C'est peut-être pédant, mais moi, j'ai tout capté lorsque je m'en suis rendu compte.

Un langage paresseux, par définition, est un langage n'évaluant les arguments des fonctions et opérateurs que lorsque ceux-ci sont réellement utilisés. Haskell est entièrement paresseux, et c'est une bonne chose.

Un langage strict est un langage évaluant les arguments des fonctions et opérateurs juste avant d'entrer dans le corps de celles-ci. Objective Caml est strict, et le problème des monades ne se pose même pas (là encore, j'y viens).

Jusque là, tout va bien.

Lorsque tu veux effectuer une série d'opérations dans un certain ordre bien défini, comme des entrées/sorties mais aussi des opérations sur les listes (List est une monade si je me souviens bien), tu dois avoir des garanties quant à l'ordre d'évaluation de ces opérations, qui peuvent être vues comme des valeurs.

Objective Caml impose un ordre (partiel, car l'ordre d'évaluation des arguments n'est pas garanti).

Haskell, lui, de par sa nature parresseuse, n'en impose pas... et pourtant, il faut bien effectuer parfois des opérations dans un ordre bien déterminé !

Le mécanisme des monades est une réponse à ce problème.

Une monade est une valeur valant à une suite d'opérations effectuées dans un ordre bien précis. En bref, les monades garantissent un ordre d'évaluation, ce que ne garantit pas, par en lui-même, le langage, justement parce qu'il est paresseux.

En Objective Caml, le problème ne se pose pas : tu es sûr que si tu écris...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
print_int (read_int (print_endline "Entrez un nombre :"))

... alors les opérations effectuées seront :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Entrez un nombre :
666
666

Le simple fait de passer des effets de bord en paramètre te garantit l'ordre dévaluation de ces effets de bord ; c'est pareil en C.

En Haskell, comme tu n'as pas cette garantie, les concepteurs ont fourni l'idée de monade, à l'intérieur de laquelle les évènements s'enchaînent de façon telle qu'ils sont écrits.

Là où ça devient intéressant, c'est que les monades étant des valeurs, elles répondent elles aussi à cette idée de paresse ! On ne peut aussi, dès lors, sortir une valeur hors de la monade, étant donné qu'à l'intérieur on est dans un cadre strict, et à l'extérieur on est dans un monde paresseux.

Il y a d'autres avantages aux monades, comme la modularité de celles-ci, mais ce sont des caractéristiques qui viennent après coup.

Voilà, j'espère ne pas avoir été trop brouillon.

[Jedai]

Je ne dirais pas celà : c'est une explication que beaucoup de personnes donnent, mais je pense que ce n'est pas la bonne.

Tu ne dirais pas quoi ? Que les monades I/O permettent une séparation de l'aspect impératif et fonctionnel qui garantit la transparence référentielle de la partie fonctionnelle ?
Peut-être pourrais-tu lire la référence que je donne avant d'expliquer que je dis des conneries ? Globalement tout ce que tu dis est déjà dans ma réponse, simplement un peu moins développé, et tous tes développements sont bien sûr bien mieux expliqué dans le document que j'ai indiqué...

Une monade est une valeur valant à une suite d'opérations effectuées dans un ordre bien précis. En bref, les monades garantissent un ordre d'évaluation, ce que ne garantit pas, par en lui-même, le langage, justement parce qu'il est paresseux.

Absolument pas. Ce qui garanti l'ordre d'évaluation c'est l'ordre de dépendance des appels de fonctions et la nécessité de commencer l'évaluation d'une valeur lorsqu'on l'explore, et effectivement dans le cas des monades, les valeurs d'une monade doivent être explorées dans l'ordre imposé par '>>=' mais il ne s'agit pas d'une propriété fondamentale du langage, les monades sont constructibles dans n'importe quel langage sans addition sémantique. Une monade n'est pas une valeur, c'est un type de donnée auquel on associe les opérations 'return' et '>>=' qui doivent respecter certaines règles pour qu'on puisse réellement parler de monades au sens de la théorie des catégories.

NB : Un langage comme Clean, bien qu'également paresseux et fonctionnel, a adopté une solution différente, il est bien évident donc que l'utilisation d'une monade n'est pas la seule façon d'imposer un ordre d'évaluation.
Par ailleurs bien qu'Haskell soit paresseux par défaut, il permet également de spécifier de l'évaluation stricte ponctuellement.

--
Jedaï

[monstre]

Objective Caml impose un ordre (partiel, car l'ordre d'évaluation des arguments n'est pas garanti).

Haskell, lui, de par sa nature parresseuse, n'en impose pas... et pourtant, il faut bien effectuer parfois des opérations dans un ordre bien déterminé !

Le mécanisme des monades est une réponse à ce problème.

Explication parfaitement limpide, merci. C'est vrai qu'un langage paresseux qui ne serait pas purement fonctionnel serait un véritable casse-tête, d'où l'intérêt des monades (dont j'apprends tout juste que c'est un nom féminin, pardonnez mon erreur).

Haskell est entièrement paresseux, et c'est une bonne chose.

Là, je suis loin d'être convaincu. Si je comprends mieux pourquoi un tel langage se doit d'être purement fonctionnel, la supériorité des langages non-stricts reste encore à démontrer. Mais ça, c'est un autre sujet...

[monstre]

Pour une description des alternatives envisagées (et parfois implémentées) et des différentes visions sémantiques qu'on peut avoir de la monade IO, je te conseille "Tackling the Awkward Squad", un excellent papier sur l'I/O, l'interfaçage avec le C, la programmation concurrente et les exceptions avec Haskell.
Toute personne vraiment intéressé par l'aspect théorique d'Haskell devrait lire cet article à mon humble avis.

Celui-là aussi, je l'avais déjà lu. Fort intéressant, mais il porte surtout sur le comment et non le pourquoi. Il existe une multitude de documents expliquant la mécanique des monades, mais bien peu se donnent la peine d'en motiver l'existence. Il n'est pas suffisant de remarquer qu'un langage paresseux nécessite l'emploi d'une telle construction; il faut d'abord justifier le choix du langage en question.

[barbouille]

... je te conseille "Tackling the Awkward Squad", un excellent papier sur l'I/O, l'interfaçage avec le C, la programmation concurrente et les exceptions avec Haskell...

Je n'arrive pas à y aller avec Firefox (y m'dit Service Unavailable l'machin ...), il m'a fallu ressortir IE pour accéder au site.

Ca vous le fait aussi ?

[alex_pi]

Ca vous le fait aussi ?

Aucun problème avec Firefox 2.0.0.12 sous linux

[Jedai]

Je n'arrive pas à y aller avec Firefox (y m'dit Service Unavailable l'machin ...), il m'a fallu ressortir IE pour accéder au site.

Ca vous le fait aussi ?

J'y accède sans problème avec Konqueror, peut-être as-tu simplement eu la malchance de tomber sur un moment où le serveur était indisponible.

--
Jedaï