Discussion :

[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 ?

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.

[Jedai]

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ï

[limestrael]

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.

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.

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...

[Jedai]

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 Haskell :

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

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.

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).

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

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

--
Jedaï

[limestrael]

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 Haskell :

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

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...

[Ubiquité]

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

[DigitalGuru]

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

Tu peux rajouter 'as' quand tu import :

Code :

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

1
2
 
import qualified Data.Map as DM