Si vous aviez quelque chose à reprocher à Haskell

Haskell est un langage excellent, bien pensé et qui a de grande qualités, mais rien n'est parfait si on essaie d'avoir un regard critique, et je pense qu'il est bien de voir tous les aspects.
Du coup, si vous aviez des choses (petites ou grosses) à lui reprocher, ça serait quoi ?

Pour ma part, ça tient du détail, mais je pense qu'un système de namespaces aurait été le bienvenu. On peut s'en rapprocher avec les imports qualifiés, mais c'est moins flexible.

Citation:

---

Envoyé par limestrael

Pour ma part, ça tient du détail, mais je pense qu'un système de namespaces aurait été le bienvenu. On peut s'en rapprocher avec les imports qualifiés, mais c'est moins flexible.

---

Là, quelque chose m'échappe, en quoi le système de module hiérarchique et divers mode d'import d'Haskell est "moins flexible" qu'un système de namespace (et d'abord quelle est la différence ? A priori j'aurais appelé ça un système de namespaces).


Pour ce qui est des reproches à adresser à Haskell... J'aimerais un système de type plus puissant ! On peut faire des choses très impressionnante avec l'actuel mais je suis convaincu qu'on peut faire encore mieux sans perdre en flexibilité. J'aimerais également un meilleur moyen de combiner les monades que les transformateurs de monades. Et il serait pratique de pouvoir traduire automatiquement du code vers une écriture monadique.

J'ai d'autres reproches qui ne me reviennent pas sur l'instant.

--
Jedaï

Citation:

---

Envoyé par Jedai

Là, quelque chose m'échappe, en quoi le système de module hiérarchique et divers mode d'import d'Haskell est "moins flexible" qu'un système de namespace (et d'abord quelle est la différence ? A priori j'aurais appelé ça un système de namespaces).

---

J'aurais aimé que l'auteur d'un module ait la capacité de définir un truc genre "namespace NS where" (un peu comme on le fait en C++).
Le souci quand on développe un code Haskell est qu'on se retrouve très rapidement avec beaucoup de fonctions, certaines ayant souvent des noms très proches (cf. certaines fonctions, genre de Data.Map, qui ont le même nom que des fonctions du Prelude) et que j'aurais aimé un moyen en plus des imports qualifiés pour répartir et retrouver mes fonctions.

Avec seulement les imports qualifiés, les problèmes sont les suivants :
- Pas moyen de définir un nom d'import standard pour un module. Ex: Je peux importer Data.Map en tant que M, mais quelqu'un d'autre pourra l'importer en tant que Map ou DM ou n'importe quoi d'autre. Ca n'aide pas pour s'y retrouver quand au sein d'un même projet on a plusieurs fois le même module, mais importé sous des noms différents. Avec un namespace Map, tout le monde serait logé à la même enseigne.
- Il faut indiquer à chaque fois les alias, alors qu'avec un namespace ce serait automatique.

Citation:

---

J'aimerais également un meilleur moyen de combiner les monades que les transformateurs de monades.

---

C'est vrai qu'un simple combinateur qui prendrait une ou plusieurs monades serait plus simple... Mais dans ce cas cela requiert quelque chose qui n'existe pas dans le langage, alors que les transformateurs de monades ne requièrent rien de spécial de la part du compilateur.

Citation:

---

Et il serait pratique de pouvoir traduire automatiquement du code vers une écriture monadique.

---

Faudrait développer un préprocesseur qui se chargerait de ça...

Citation:

---

Envoyé par limestrael

Avec seulement les imports qualifiés, les problèmes sont les suivants :
- Pas moyen de définir un nom d'import standard pour un module. Ex: Je peux importer Data.Map en tant que M, mais quelqu'un d'autre pourra l'importer en tant que Map ou DM ou n'importe quoi d'autre. Ca n'aide pas pour s'y retrouver quand au sein d'un même projet on a plusieurs fois le même module, mais importé sous des noms différents. Avec un namespace Map, tout le monde serait logé à la même enseigne.
- Il faut indiquer à chaque fois les alias, alors qu'avec un namespace ce serait automatique.

---

En fait tu lui reproches sa flexibilité excessive non ? Par ailleurs, il y a un nom de base pour l'espace de nom de Data.Map... c'est Data.Map :

Code:

---

1 2 3

import qualified Data.Map   stuff = Data.Map.lookup blabla

---

(c'est aussi valable sans le qualified d'ailleurs : tu peux toujours utiliser Data.Map.lookup pour éviter une ambiguité)
Ce que "as" t'apporte de plus c'est la possibilité de définir un alias.

Citation:

---

Envoyé par limestrael

C'est vrai qu'un simple combinateur qui prendrait une ou plusieurs monades serait plus simple... Mais dans ce cas cela requiert quelque chose qui n'existe pas dans le langage, alors que les transformateurs de monades ne requièrent rien de spécial de la part du compilateur.

---

Ce n'est pas ce que je voulais dire : les transformateurs de monades tels qu'écrit actuellement sont fragiles (certaines combinaisons violent certaines lois de monades) et relativement ennuyeux à écrire, il y a des travaux pour rendre cela plus solide et simple (c'est une question de trouver la bonne abstraction, pas besoin de sortir du langage pour ça).

Citation:

---

Envoyé par limestrael

Faudrait développer un préprocesseur qui se chargerait de ça...

---

Plutôt du ressort de la refactorisation à mon avis.

--
Jedaï

Citation:

---

Envoyé par Jedai

En fait tu lui reproches sa flexibilité excessive non ? Par ailleurs, il y a un nom de base pour l'espace de nom de Data.Map... c'est Data.Map :

Code:

---

1 2 3

import qualified Data.Map   stuff = Data.Map.lookup blabla

---

(c'est aussi valable sans le qualified d'ailleurs : tu peux toujours utiliser Data.Map.lookup pour éviter une ambiguité)
Ce que "as" t'apporte de plus c'est la possibilité de définir un alias.

---

Oui, mais là pour le coup Data.Map c'est un peu long à taper à chaque fois... 8-)

Haskell est dur a apprendre. En tout cas pour quelqu'un comme moi qui ne connait que l'objet et le procédural.

Explique-toi.
Si Haskell est dur à apprendre parce qu'il fonctionne d'une manière très différente de ce que tu connais, ça ne peut pas être une critique. Si Haskell fonctionnait pareil que les langages mainstream, il aurait beaucoup moins d'intérêt. Il est intéressant avant justement tout parce qu'il propose un modo operandum et une logique différents.

Si maintenant tu trouves qu'Haskell est dur à apprendre parce qu'il te semble que ses créateurs ne font pas d'effort pour aider les débutants (qui en d'autant plus besoin du fait de sa logique différente), ça c'est autre autre chose.
Effectivement, les messages d'erreur de GHC sont assez opaques pour le newbie.

Ben tu demandes si on a un reproche a faire a Haskell, moi j'en ai un.
Après si il est impossible de corriger cette imperfection sans dénaturer totalement le langage, alors il faut trouver une autre réponse (le faire enseigner dans les université, écoles, par exemple).

Citation:

---

Envoyé par limestrael

Oui, mais là pour le coup Data.Map c'est un peu long à taper à chaque fois... 8-)

---

Tu peux rajouter 'as' quand tu import :

Code:

---

1 2	import qualified Data.Map as DM

---

- le compilateur GHC est trop compliqué, lourd, et long à compiler
- rentre GHCi agréable à utiliser pour coder de petits exemples (quand on est habitué au toplevel OCaml, il y a un monde)

- si on pouvait reconcevoir haskell aujourd'hui, j'essaierais d'enlever la paresse par défaut (par exemple, en ajoutant des spécifications d'appel sur les types des fonctions, où on choisit entre un traitement lazy ou strict de chaque paramètre, le défaut étant le strict)

- essayer de concevoir un meilleur support pour les ambiguités de type classes : je veux pouvoir donner plusieurs structures de monoïde à l'ensemble des entiers naturels, sans devoir changer de type; cela passe sans doute par une réification de certains dictionnaires

- ajouter un mot-clé "rec" ou un équivalent pour préciser les valeurs récursives; dans le cas par défaut, les noms déclarés ne seraient pas dans la portée de leur déclaration

- un langage de contraintes plus puissant et plus composable (il y a un article à ce sujet : Haskell Type Constraints Unleashed)

- arrêter de traiter la monade IO comme un gros blurb où on peut tout mettre (entrée-sortie, concurrence..)

- des outils pour rendre plus facile la programmation au niveau des types, comme par exemple une couche de langage logique spécialisée, ou la définition d'un sous-ensemble de Haskell où aucune valeur ne diverge, pour pouvoir l'utiliser dans les types (mais sans forcément autoriser les types dépendants dans toute leur généralité, pour préserver la distinction typage/exécution)


Edit : un petit point auquel j'avais déjà pensé, que j'ai oublié de mentionner, mais que je viens de retrouver très bien exprimé dans un post de Tim Sweeney : pas de différence entre la syntaxe (ou la sémantique) des déclarations toplevel et des déclarations locales.

Citation:

---

Envoyé par bluestorm

- rentre GHCi agréable à utiliser pour coder de petits exemples (quand on est habitué au toplevel OCaml, il y a un monde)

---

Tu pourrais préciser ? Personnellement je préfère largement GHCi ne serait-ce que pour l'autocomplétion et la mémorisation des expressions entrées.

Le fait que la syntaxe des déclarations dans GHCi et dans le Haskell classique soient très différentes est assez pénalisant. En pratique je n'arrive jamais à entrer des programmes de plus d'une ligne dans GHCi.

En gros, il est impossible d'utiliser GHCi pour coder, même de petites choses : tout ce que j'arrive à lui demander, c'est le type ou la valeur d'expressions venant d'un programme externe. C'est pratique, mais ça limite sérieusement l'utilité d'un interpréteur interactif (par rapport par exemple à un éditeur qui donne des informations de typage si on lui demande gentiment).

Ce sont des problèmes de surface, moins importants que d'autres (mais en même temps la syntaxe toplevel des déclarations Haskell doit contribuer à la difficulté de faire une REPL pratique à utiliser; mais on pourrait ajouter un opérateur pour dire "c'est la fin d'un bloc de déclarations", un peu comme le ';;' OCaml).

Citation:

---

Envoyé par bluestorm

- ajouter un mot-clé "rec" ou un équivalent pour préciser les valeurs récursives; dans le cas par défaut, les noms déclarés ne seraient pas dans la portée de leur déclaration

---

Je serais intéressé de savoir en quoi c'est important. Pour moi, cela permet d'éliminer un mot-clé, et le seul désavantage que je vois est qu'on ne peut pas référencer une ancienne valeur liée à cet identifiant, ce qui me semble un mauvais style de toute façon (cela peut donner l'impression que la valeur est récursive si on ne fait pas assez attention).

Citation:

---

Pour moi, cela permet d'éliminer un mot-clé

---

Et alors ? On parle de Haskell (qui a trois mots-clés pour les déclarations de type), pas d'un langage minimaliste, il n'y a pas de honte à ajouter un mot-clé s'il a une signification sémantique intéressante.

L'intérêt de pouvoir accéder aux anciennes valeurs n'est en fait pas tellement le fait d'y accéder, mais surtout le fait de pouvoir les cacher. Dans un certain nombre de contextes, on a envie de mettre à jour une valeur, et on veut s'assurer que toutes les références suivantes se feront sur la nouvelle.

Le cas typique est du style "let x = secure x in ..." : on veut cacher la définition de la valeur x, en la remplaçant par une valeur "sécurisée", et faire référence ensuite à la version sécurisée. En haskell on utilise des "... where x' = secure x", mais le risque est alors de se tromper et d'écrire x au lieu de x'. Si les deux valeurs ne sont pas du même type, le compilateur détecte l'erreur, mais ce n'est pas toujours le cas.

Exemples trouvés dans du vrai code, par Google Code Search :

Code:

---

1 2	int8ToInt (I8 x) = if x' <= 0x7f then x' else x' - 0x100 where x' = x `primAnd` 0xff

---

Code:

---

1 2 3 4 5 6 7 8 9

hash_fetchElem hv idx = do let idx' = encodeKey idx r <- liftIO $ H.lookup hv idx' case r of Just sv -> return sv Nothing -> do sv <- newScalar undef liftIO $ H.insert hv idx' sv return sv

---

Code:

---

1 2 3 4 5 6 7

> qualBindNestEnv x y (LocalEnv genv env) > | isQualified x = error "internal error: qualBindNestEnv" > | otherwise = > case lookupEnv x' env of > Just _ -> error "internal error: qualBindNestEnv" > Nothing -> LocalEnv genv (bindEnv x' y env) > where x' = unqualify x

---

Dans aucun de ces codes on n'a besoin de conserver la référence à x (il y a des fois où on veut pouvoir accéder par la suite à la fois à l'ancienne valeur et la nouvelle), donc il n'y a aucune raison de ne pas cacher l'ancien binding.

Il vaut mieux réserver ce style aux cas où justement, on a besoin de l'ancienne référence (ce sont en général des cas assez subtils où il faut faire bien attention, donc il est important de mettre l'accent sur l'utilisation à un endroit de x ou de x'), et cacher dans le reste des cas le binding, ce qui enlève un poids mental sur le programmeur en réduisant le nombre d'identifiants actifs, et le risque d'erreur.

Il n'y a pas de risque de confondre cela avec une définition récursive, puisque les récursions seraient explicitement marquées par "rec". Il suffit de vérifier la présence ou non de "rec" pour savoir si une définition est récursive, et de toute façon tous les exemples que j'ai montrés sont évidemment non-récursifs (à part les petits malins qui s'amusent à faire du "Tying back the knot", personne de sain d'esprit n'écrirait "x = secure x" si c'était récursif).

On a déjà discuté de ça par ici, et certains Haskelliens ont répondu, et je pense qu'ils n'ont pas forcément tort, que Haskell favorise le style récursif car il s'allie bien avec la paresse par défaut (l'idée plus ou moins vraie que tout ce qu'on définit est un cofixpoint). Dans ce cas, on pourrait imaginer un mot clé "nonrec" à mettre dans l'autre sens, pour permettre tout de même les idiomes que j'ai montrés. Je pense cependant que le style récursif est celui qu'il convient de marquer explicitement (même en Haskell la récursion n'est pas si courante, surtout avec l'emploi lourds de combinateurs tels que fold/map/etc.), surtout si on le combine avec mon idée d'explorer des possibilités de ne pas avoir la paresse par défaut.




Enfin, il y a des situations en métaprogrammation où on a envie de générer des programmes en surveillant la portée des identifiants, pour empêcher certaines choses. Il est facile d'utiliser des déclarations locales pour éviter qu'un identifiant ne se propage en dehors d'un bloc, mais la syntaxe Haskell actuelle empêche de cacher un identifiant dans sa portée lexicale, ce qui peut être un problème.

Par exemple, dans le papier "Comprehensive Comprehensions" (Wadler and Peyton Jones, 07), qui propose une syntaxe de list comprehension en Haskell avec des fonctionnalités empruntées de SQL, on trouve la proposition suivante pour GROUP BY :

Code:

---

1 2 3 4 5 6

the :: Eq a => [a] -> a the (x:xs) | all (x ==) xs = x   [ (the dept, sum salary) | (name, dept, salary) <- employees , group by dept ]

---

Dans ce code, (name, dept, salary) sont des champs extraits de la liste "employees", et l'opération "group by" les transforme en listes (GROUP BY dept renvoie une liste de classes d'équivalences pour la relation "être du même département"). Ensuite on récupère la valeur département et on fait la somme des salaires.

Si on imagine qu'on traduit cette syntaxe vers du code Haskell standard, la redéfinition peut poser problème : il est possible que la nouvelle déclaration des variables comme liste utilise l'ancienne déclaration des variables comme éléments (surtout si les variables utilisées dans le code généré ne représentent pas les variables elles-même, mais une description abstraite des variables, comme on doit faire si on espère par exemple générer une requête SQL à la fin (ce qui n'est pas le cas dans l'article)). La syntaxe Haskell de haskell pose alors problème, et il faut faire des acrobaties diverses pour éviter les captures/récursions.

Citation:

---

Envoyé par limestrael

Haskell est un langage excellent, bien pensé et qui a de grande qualités, mais rien n'est parfait si on essaie d'avoir un regard critique, et je pense qu'il est bien de voir tous les aspects.
Du coup, si vous aviez des choses (petites ou grosses) à lui reprocher, ça serait quoi ?

---

100% d'accord avec bluestorm (sauf sur l'évaluation stricte par défaut où je suis plus partagé).

J'ajouterais un seul reproche :

• pas de vérification de l'exhaustivité du filtrage

Mais si j'avais à faire la liste des reproches à OCaml elle serait au moins aussi longue (pauvreté des types entiers de base, boxed floats, code mort dans les modules, pas de région-based memory-management,...,...).

Je suis d'accord sur l'exhaustivité des filtrages, mais je pense qu'il faudrait une construction syntaxique pour la désactiver localement (car parfois on a envie de dire que seul un cas est possible).

Pour les reproches à OCaml, je t'invite à créer un topic à ce sujet, ce serait certainement intéressant. D'ailleurs, j'ai du rater quelque chose car je ne comprends pas pourquoi tu reproches à Caml l'absence de régions, alors qu'à ma connaissance Haskell n'en a pas. Est-ce que Haskell en a déjà, ou tu penses que ce ne serait pas utile/pertinent dans ce langage ?

Je pense que tous les langages devraient avoir le region-based memory-management.
À commencer par le D et autres prétendants à la succession du C.

Citation:

---

Envoyé par bluestorm

Pour les reproches à OCaml, je t'invite à créer un topic à ce sujet, ce serait certainement intéressant.

---

Ça risquerait d'être plus cacophonique parce que les styles sont plus diversifiés en OCaml. Il y aurait les pour et les contre le return et on s'étriperait joyeusement pour rien du tout.

GHC permet déjà de vérifier l'exhaustivité des filtrages avec -fwarn-incomplete-patterns (ou -Wall), il y a aussi l'outil Catch qui est censé être capable dans certains cas de vérifier que des patterns partiels traitent correctement tous les cas possibles.

@bluestorm :

Citation:

---

- le compilateur GHC est trop compliqué, lourd, et long à compiler

---

D'un autre côté en tant que simple utilisateur, tu n'es pas censé le compiler par toi-même (évidemment, si tu tiens à développer GHC, la question est tout autre). Par trop compliqué, je suppose que tu parles du code source, car l'utilisation de GHC est très simple.

Citation:

---

- rentre GHCi agréable à utiliser pour coder de petits exemples (quand on est habitué au toplevel OCaml, il y a un monde)

---

C'est une question d'habitude de travail, je trouve GHCi très pratique à utiliser en conjonction avec un bon éditeur de texte pour taper les fonctions longues. De plus si tu connais un peu la syntaxe explicite (sans layout), tu peux taper des fonctions complexes dans GHCi sans problème.
Reste que GHCi ne permet pas de déclarer des nouveaux types ou instances, il serait intéressant de rendre cela possible (il n'y a pas a priori d'obstables techniques réels).

Citation:

---

- si on pouvait reconcevoir haskell aujourd'hui, j'essaierais d'enlever la paresse par défaut (par exemple, en ajoutant des spécifications d'appel sur les types des fonctions, où on choisit entre un traitement lazy ou strict de chaque paramètre, le défaut étant le strict)

- ajouter un mot-clé "rec" ou un équivalent pour préciser les valeurs récursives; dans le cas par défaut, les noms déclarés ne seraient pas dans la portée de leur déclaration

---

Tu peux parfaitement reconcevoir Haskell aujourd'hui, il me semble toutefois que la paresse par défaut est consubstantielle à Haskell, un langage qui n'aurait pas cela ne serait pas Haskell. Dans cette même optique, "rec" ne m'intéresse pas, bien que "nonrec" puisse avoir un petit intérêt ("case secure x of x -> ..." permet déjà de masquer une variable).

Je suis d'accord avec le reste de tes remarques.

--
Jedaï

Je pourrais aussi reprocher un léger manque de consistance au niveau de certains opérateurs (notamment la '->' qui est allègrement utilisée partout).

Par exemple, une fonction se déclare ainsi:
f x = 3*x
Pourquoi une fonction lambda n'est-elle pas déclarée ainsi:
\x = 3*x
au lieu de \x -> 3*x ?

Parce que la première ligne est une égalité (f, appliqué à x, égale 3 x), alors que dans la deuxième il n'y a rien d'égal : "\x = 3*x" suggèrerait au mieux que x = 3*x, donc une forme de récursion. Il s'agit ici d'une fonction : à x on associe 3x. Le "->" est d'ailleurs bien le même "->" que dans un motif ("case .. of") par exemple : si on reconnaît le motif "x", on renvoie "3*x".

moi ce serait un reproche tout bête : l'indentation.
Combien de fois je me suis fais avoir par des erreurs venant du fait qu'il y avait un "tab" en début de ligne au lieu de 3 ou 4 espaces...

Après je pense qu'un IDE le rendrait plus populaire... A moins qu'il en éxiste déja un et que je ne l'ai jamais trouvé ?

Sinon le langage est bien pratique, j'ai fais un projet de manipulation algébrique de graphe avec...

Citation:

---

Envoyé par michon

moi ce serait un reproche tout bête : l'indentation.
Combien de fois je me suis fais avoir par des erreurs venant du fait qu'il y avait un "tab" en début de ligne au lieu de 3 ou 4 espaces...

---

Pourtant le système dans lequel l'indentation a de l'importance est optionnel (même si en pratique c'est le plus employé); on peut écrire en effet

Code:

---

1 2 3 4

main = do { action1; action2 ; action3; action4 ; }

---

(exemple volontairement massacré)

là ou on écrit en général

Code:

---

1 2 3 4 5

main = do action1 action2 action3 action4

---

Citation:

---

Envoyé par bluestorm

Parce que la première ligne est une égalité (f, appliqué à x, égale 3 x), alors que dans la deuxième il n'y a rien d'égal : "\x = 3*x" suggèrerait au mieux que x = 3*x, donc une forme de récursion. Il s'agit ici d'une fonction : à x on associe 3x. Le "->" est d'ailleurs bien le même "->" que dans un motif ("case .. of") par exemple : si on reconnaît le motif "x", on renvoie "3*x".

---

Ton explication n'est pas très claire, en cela que je ne vois pas en quoi
\x = 3*x suggère que x = 3*x. On peut également avoir la suggestion que \x = 3*x "lambda x égale 3 fois x", ce qui suggère fonction anonyme qui à un paramètre x associe le résultat 3*x.

Ton explication sur la cohérence avec les motifs case ... of me plait mieux. :)

Citation:

---

Envoyé par bluestorm

- rentre GHCi agréable à utiliser pour coder de petits exemples (quand on est habitué au toplevel OCaml, il y a un monde)

---

Ouais on peut pas coder avec vu qu'on n'est dans un autre mode de fonctionnement que dans un fichier source, très mauvais pour le débutant.

Citation:

---

Envoyé par bluestorm

- si on pouvait reconcevoir haskell aujourd'hui, j'essaierais d'enlever la paresse par défaut (par exemple, en ajoutant des spécifications d'appel sur les types des fonctions, où on choisit entre un traitement lazy ou strict de chaque paramètre, le défaut étant le strict)

---

Hérésie :D.

Citation:

---

Envoyé par bluestorm

- essayer de concevoir un meilleur support pour les ambiguités de type classes : je veux pouvoir donner plusieurs structures de monoïde à l'ensemble des entiers naturels, sans devoir changer de type; cela passe sans doute par une réification de certains dictionnaires

---

Ça c'est un vrai problème (mais je n'ose regarder ce que font les autres).

Citation:

---

Envoyé par bluestorm

- ajouter un mot-clé "rec" ou un équivalent pour préciser les valeurs récursives; dans le cas par défaut, les noms déclarés ne seraient pas dans la portée de leur déclaration

---

Totally useless. En ocaml il me soule. Et sa seule et unique utilité serait si j'ai deux fonctions avec le même nom. Donc non c'est un truc de dégueulasse.

Citation:

---

Envoyé par bluestorm

- arrêter de traiter la monade IO comme un gros blurb où on peut tout mettre (entrée-sortie, concurrence..)

---

Tout ce qui fait un effet de bord doit être la dedans. On n'y peut rien. Après pas mal de développeuirs ne comprennent pas que IO n'est pas une poubelle.

Il y a un point qu'on peut reprocher à Haskell : il ne fait pas de POO. Il y a de rares cas (contrôles d'une interface graphique) où c'est extrêmement utile.

Citation:

---

Envoyé par NokyDaOne

Il y a un point qu'on peut reprocher à Haskell : il ne fait pas de POO. Il y a de rares cas (contrôles d'une interface graphique) où c'est extrêmement utile.

---

En même temps gtk2hs s'en sort pas mal, non ?

Ouais le jour où ça buildera sur les trois OS sans pb. Aujourd'hui je n'ai pas encore réussi à builder ce genre de choses.

Un truc tout bête : la fonction split n'existe pas dans Data.List !!!

Evidemment, Google is my friend trouve plein de solutions, mais si c'était codé dans le module ce serait quand même mieux.

A noter sa présence dans Data.Text

Eh puis un truc tout de même inconcevable.

Haskell défini des monoïdes, ce qui plait vraiment bien au mathématicien qui sommeille (parfois) en nous.

Pour mémoire, en maths, un monoïde est une structure algébrique consistant en un ensemble muni d'une loi de composition interne associative et d'un élément neutre.

Bien, et là, comment s'appelle en Haskell l'élément neutre et la loi de composition interne ?
respectivement mempty et mappend !!!
quand même, quel dommage ...

Citation:

---

Envoyé par NokyDaOne

Il y a un point qu'on peut reprocher à Haskell : il ne fait pas de POO. Il y a de rares cas (contrôles d'une interface graphique) où c'est extrêmement utile.

---

Mmmh... Pas sûr. Je viens de passer 5 mois à coder en Python en paradigme fonctionnel, et je peux t'assurer que les concepts objets se mélangent très mal avec les principes fonctionnels. Types immutables et héritage, par exemple, sont une combinaison assez bancale, notamment en ce qui concerne les classes abstraites.
En fait, au final, je n'utilise quasiment que des types immutables (et rien ne m'assure que je suis à l'abri d'une erreur, puisque les listes par ex en Python n'ont pas de version immutable) et très peu d'héritage.

Scala mélange excellemment objet et fonctionnel, car il encourage l'utilisation de structures de données immutables (les types de base existent en 2 versions: mutable et immutable) et dispose de primitives en ce sens (case classes et pattern matching notamment) qui s'inspirent d'ailleurs grandement de ce qu'on trouve en ML/Haskell. Le fait qu'une variable puisse être déclarée soit mutable ('var') soit immutable ('val') apporte beaucoup.

Remarque, il exite O'Haskell (je ne l'ai jamais testé) qui ajoute une couche objet sur Haskell.

Pour réaliser des GUI, je te suggère de jeter un coup d'oeil du côté de la FRP (programmation fonctionnelle réactive, avec des librairies comme elerea, reactive ou yampa).
Alors, c'est pas simple (yampa utilise les arrows en plus, et est bien compliqué de base), mais les principes utilisés sont assez puissants et élégants.

Les types algébriques et les records comme on a en Haskell sont une approche alternative à la POO pour modéliser des données. De la même façon, plutôt qu'une classe implémente une interface / dérive d'une classe abstraite, hé bien ton type de données va être instance d'une typeclass.

Les deux approches sont différentes, mais il n'y en a pas vraiment une qui est plus puissante que l'autre. Chacune a des avantages.

(plus le temps passe, plus j'en trouve à l'approche Haskell, malgré mes 6 ans de C++...)