Rassurez vous, Haskell gère très bien l'Unicode, mais pas pour l'affichage dans une structure imbriquée.
Ce passage peut intriguer... Le problème n'est pas tant qu'Haskell ne gère pas l'affichage d'Unicode dans une structure imbriquée (pour le coup ce serait problématique !) mais qu'ici Guillaum utilise la fonction print, cette fonction affiche le résultat de show sur son argument et cette fonction est destiné au débogage ou à l'affichage rapide de valeurs quelconques dont le type est une instance de la typeclass Show. L'objectif n'a jamais été de présenter correctement ou joliment une structure de donnée mais plutôt d'en donner une expression qu'on puisse éventuellement recoller dans son code sans problème. En particulier l'instance de Char est telle que lorsqu'on show un caractère hors de l'ASCII, son code caractère est affiché à la place, de sorte qu'on puisse le recoller dans le source sans aucun problème de compatibilité.
Si à la place vous utilisez putStr sur une String comportant de l'Unicode, vous verrez que cela fonctionne parfaitement (pour peu que votre locale soit bien réglée).
Ici par exemple on pourrait utiliser :
showResult::Maybe[String]->IO()showResultm=putStr(maybe"Pas dans le dictionnaire"unlinesm)
Qui afficherait un anagramme (accents compris) par ligne, ou "Pas dans le dictionnaire" si le mot n'est pas trouvé.
Ligne 11, définition de getAnagram qui regarde dans la structure si la clé y est. Pas d'opérateur pour l'accès aux cases d'un dictionnaire en Haskell, il faut utiliser Map.lookup qui renvoie Nothing si la clé n'existe pas ou Just value si elle existe.
Il existe en fait un opérateur : (!) comme dans dict ! "clé" mais la plupart des utilisateurs d'Haskell préfère la fonction lookup car celle-ci renvoie une valeur de type Maybe ... et oblige donc l'utilisateur à traiter le cas où la clé n'existe pas dans le dictionnaire plutôt que de soulever une exception comme le fait (!). On peut dire que cette différence résume bien l'esprit d'Haskell : ne pas utiliser de fonction partielles (qui peuvent échouer sur certaines entrées), préférer encoder le fait qu'une fonction puisse échouer dans son type de sorte qu'un utilisateur doive traiter le cas d'erreur (mais fournir des combinateurs comme maybe pour rendre cela facile !!).
Notez que les opérateurs en Haskell sont des fonctions comme les autres (en dehors de leur syntaxe) et peuvent être définis dans n'importe quel module. C'est une force qui peut parfois être légèrement abusée au goût de certains... ;-)
# Unicode et Haskell
Posté par Chaddaï Fouché . En réponse à la dépêche Le compilateur GHC Haskell en version 8.0.1. Évalué à 3.
Ce passage peut intriguer... Le problème n'est pas tant qu'Haskell ne gère pas l'affichage d'Unicode dans une structure imbriquée (pour le coup ce serait problématique !) mais qu'ici Guillaum utilise la fonction
print, cette fonction affiche le résultat deshowsur son argument et cette fonction est destiné au débogage ou à l'affichage rapide de valeurs quelconques dont le type est une instance de la typeclassShow. L'objectif n'a jamais été de présenter correctement ou joliment une structure de donnée mais plutôt d'en donner une expression qu'on puisse éventuellement recoller dans son code sans problème. En particulier l'instance deCharest telle que lorsqu'onshowun caractère hors de l'ASCII, son code caractère est affiché à la place, de sorte qu'on puisse le recoller dans le source sans aucun problème de compatibilité.Si à la place vous utilisez
putStrsur uneStringcomportant de l'Unicode, vous verrez que cela fonctionne parfaitement (pour peu que votre locale soit bien réglée).Ici par exemple on pourrait utiliser :
Qui afficherait un anagramme (accents compris) par ligne, ou "Pas dans le dictionnaire" si le mot n'est pas trouvé.
Il existe en fait un opérateur :
(!)comme dansdict ! "clé"mais la plupart des utilisateurs d'Haskell préfère la fonctionlookupcar celle-ci renvoie une valeur de typeMaybe ...et oblige donc l'utilisateur à traiter le cas où la clé n'existe pas dans le dictionnaire plutôt que de soulever une exception comme le fait(!). On peut dire que cette différence résume bien l'esprit d'Haskell : ne pas utiliser de fonction partielles (qui peuvent échouer sur certaines entrées), préférer encoder le fait qu'une fonction puisse échouer dans son type de sorte qu'un utilisateur doive traiter le cas d'erreur (mais fournir des combinateurs commemaybepour rendre cela facile !!).Notez que les opérateurs en Haskell sont des fonctions comme les autres (en dehors de leur syntaxe) et peuvent être définis dans n'importe quel module. C'est une force qui peut parfois être légèrement abusée au goût de certains... ;-)