IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Haskell Discussion :

[Haskell] Raison d'être du monade IO?


Sujet :

Haskell

  1. #1
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut [Haskell] Raison d'être du monade IO?
    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.

  2. #2
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  3. #3
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par gorgonite
    J'ai lu la version anglaise, qui n'avait de gentle que le nom, et ma question demeure entière.

  4. #4
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    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ï

  5. #5
    Membre éprouvé
    Avatar de InOCamlWeTrust
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 036
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 036
    Points : 1 284
    Points
    1 284
    Par défaut
    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.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  6. #6
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par 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.
    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ï

  7. #7
    Membre éprouvé
    Avatar de InOCamlWeTrust
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 036
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 036
    Points : 1 284
    Points
    1 284
    Par défaut
    Citation Envoyé par Jedai
    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 ?
    Jamais dit que tu disais des conneries, mais elles font beaucoup plus que séparer l'aspect fonctionnel et impératif. Ce qui me dérange, c'est que l'on restreigne ainsi leur portée aux seules entrées/sorties.

    Citation Envoyé par Jedai
    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.
    Je sais et je n'ai jamais dit le contraire : je ne vois pas pourquoi tu t'énerves.

    Citation Envoyé par Jedai
    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.
    Si c'est un type de données, alors les valeurs de ce type de données, c'est quoi ?

    Citation Envoyé par Jedai
    Par ailleurs bien qu'Haskell soit paresseux par défaut, il permet également de spécifier de l'évaluation stricte ponctuellement.
    Oui, tout à fait, mais ça n'est pas dans l'esprit du langage qui se veut entièrement paresseux. C'est essentiellement une caractéristique ajoutée après coup pour rendre les programmes plus performants.
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  8. #8
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par InOCamlWeTrust
    Jamais dit que tu disais des conneries, mais elles font beaucoup plus que séparer l'aspect fonctionnel et impératif.
    Je ne dirais pas celà : c'est une explication que beaucoup de personnes donnent, mais je pense que ce n'est pas la bonne.
    En bref, mon explication n'est pas bonne, j'ai donc dit une connerie, non ? (C'est crûment dit, je l'admets, peut-être fais-je porter à ce terme moins de poids que d'autres)

    Ce qui me dérange, c'est que l'on restreigne ainsi leur portée aux seules entrées/sorties.
    La monade IO est destinée aux entrées/sorties. Si on parle des monades en général bien sûr la portée est beaucoup plus générale. Evidemment si nous ne répondons pas à la même question je suppose qu'il est normal que nous n'obtenions pas les mêmes réponses...

    Si c'est un type de données, alors les valeurs de ce type de données, c'est quoi ?
    Et bien par exemple [1,2,3,4] est une valeur dans la monade List (abréviation pour désigner le triplet (Data.List, >>= :: [a] -> (a -> [b]) -> [b], return :: a -> [a]) qui constitue une monade).

    --
    Jedaï

  9. #9
    Membre éprouvé
    Avatar de InOCamlWeTrust
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 036
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 036
    Points : 1 284
    Points
    1 284
    Par défaut
    Citation Envoyé par Jedai
    Et bien par exemple [1,2,3,4] est une valeur dans la monade List (abréviation pour désigner le triplet (Data.List, >>= :: [a] -> (a -> [b]) -> [b], return :: a -> [a]) qui constitue une monade).
    Mouais...
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  10. #10
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par InOCamlWeTrust
    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).

    Citation Envoyé par InOCamlWeTrust
    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...

  11. #11
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par monstre
    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...
    En dehors des problèmes techniques qui tendent à ralentir un langage paresseux, je ne vois pas très bien comment on peut arguer qu'un langage strict est supérieur à un non-strict : le non-strict permet de compléter plus de programmes, ne calcule que ce qui est vraiment nécessaire, permet d'utiliser facilement des structures de données infinies...

    Evidemment, ça peut parfois poser des problèmes pour évaluer la complexité temporelle ou spatiale d'un programme donné.

    --
    Jedaï

  12. #12
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par Jedai
    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.

  13. #13
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par Jedai
    En dehors des problèmes techniques qui tendent à ralentir un langage paresseux, je ne vois pas très bien comment on peut arguer qu'un langage strict est supérieur à un non-strict : le non-strict permet de compléter plus de programmes, ne calcule que ce qui est vraiment nécessaire, permet d'utiliser facilement des structures de données infinies...

    Evidemment, ça peut parfois poser des problèmes pour évaluer la complexité temporelle ou spatiale d'un programme donné.
    Je crois que tu viens de répondre à ta propre question.

  14. #14
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par monstre
    Je crois que tu viens de répondre à ta propre question.
    Néanmoins il ne s'agit pas d'un désavantage en pratique, juste en théorie. Et il est également possible la plupart du temps de placer une borne supérieure sur ces complexités en considérant le programme strict équivalent s'il existe. Parfois il faut raffiner de façon à trouver ce programme strict équivalent, et on peut affiner son estimation des complexités une fois la borne établie, mais ce n'est pas un si gros problème.

    Et une fois mis en balance avec les avantages pratiques et théoriques des langages non-strict...

    --
    Jedaï

  15. #15
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par Jedai
    Néanmoins il ne s'agit pas d'un désavantage en pratique, juste en théorie.
    Merci de justifier cette affirmation. S'il me prenait l'envie de calculer la factorielle de 1 000 000 en pratique, qu'est-ce se passerait? Dans un langage comme Scheme ou ML, cette fonction est O(1) en mémoire en utilisant la récursion terminale. Et en Haskell? Exception: stack overflow.

  16. #16
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par monstre
    Merci de justifier cette affirmation. S'il me prenait l'envie de calculer la factorielle de 1 000 000 en pratique, qu'est-ce se passerait? Dans un langage comme Scheme ou ML, cette fonction est O(1) en mémoire en utilisant la récursion terminale. Et en Haskell? Exception: stack overflow.
    Uniquement si tu as compilé sans aucunes optimisations, et essayer de calculer en mode interactif 1000000! n'est pas vraiment recommandable.

    --
    Jedaï

  17. #17
    Membre éprouvé
    Avatar de InOCamlWeTrust
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    1 036
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 036
    Points : 1 284
    Points
    1 284
    Par défaut
    Quand je disais que Haskell est paresseux et que c'est une bonne idée, c'est parce qu'avec un tel langage, tu peux t'autoriser à faire des trucs impensables tels quels dans les langages stricts, du style "Je calcule tous les états possibles de ce jeu, que je mets, dans une liste et je filtre ensuite les états qui m'intéressent". Avec un langage strict, ce genre de chose est infaisable car la liste serait calculée avant même d'avoir commencé à filtrer... en Haskell, non, car seuls les états courament utiles dans le filtrage seront évalués.

    De plus, je continue à penser que les langages fonctionnels purs stricts sont une hérésie, mais ça, je sais qu'il y en a beaucoup ici qui ne sont pas d'accord avec moi !
    When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.

  18. #18
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par Jedai
    Uniquement si tu as compilé sans aucunes optimisations, et essayer de calculer en mode interactif 1000000! n'est pas vraiment recommandable.
    Et faire dépendre ainsi la complexité d'une fonction sur le compilateur utilisé et le niveau d'optimisation, c'est recommandable? Comment peut-on déduire quoi que ce soit a priori sur la complexité spatiale d'un programme dans de telles conditions? Je me répète, mais dans un langage comme Scheme, la récursion terminale est garantie constante en mémoire indépendamment du compilateur, ce qui constitue un réal avantage « en pratique ».

  19. #19
    Expert éminent
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2003
    Messages
    6 245
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : Avril 2003
    Messages : 6 245
    Points : 8 586
    Points
    8 586
    Par défaut
    Citation Envoyé par monstre
    Et faire dépendre ainsi la complexité d'une fonction sur le compilateur utilisé et le niveau d'optimisation, c'est recommandable?
    Non, ça n'est pas recommandable, c'est juste très souvent le cas dès lors qu'on parle d'optimisation et de compilateur, quel que soit le langage.
    Je n'appelle pas ça un problème "en pratique" si je n'ai aucune chance de tomber dessus en ayant une pratique normale du langage.

    --
    Jedaï

  20. #20
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2007
    Messages
    11
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Juin 2007
    Messages : 11
    Points : 3
    Points
    3
    Par défaut
    Citation Envoyé par InOCamlWeTrust
    Quand je disais que Haskell est paresseux et que c'est une bonne idée, c'est parce qu'avec un tel langage, tu peux t'autoriser à faire des trucs impensables tels quels dans les langages stricts, du style "Je calcule tous les états possibles de ce jeu, que je mets, dans une liste et je filtre ensuite les états qui m'intéressent".
    Je ne doute pas de l'utilité de l'évaluation de l'évaluation paresseuse. Je dis seulement que :
    - elle complique l'analyse des programmes (cf. message précédent);
    - elle aurait peut-être avantage à être appliquée avec parcimonie plutôt que par défaut.
    Mais comme je disais, on s'écarte un peu du sujet initial, que je considère clos suite à ta réponse précédente. Encore merci pour ces explications.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. graphe effacé peut-être sans raison
    Par AlfredKr dans le forum Débuter
    Réponses: 2
    Dernier message: 29/10/2014, 09h52
  2. Réponses: 9
    Dernier message: 12/10/2011, 15h27
  3. Réponses: 2
    Dernier message: 21/03/2002, 00h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo