Bonjour Gautier,
Je ne vois pas trop la partie TDD, je trouve personnellement les tests peu expressifs. IMHO illustrer le TDD en Haskell implique de partir de Quickcheck. Tes tests sur l'égalité et les propriétés des Temperatures pourraient tirer parti de cet outil par exemple. Par ailleurs si tu veux utiliser HSpec alors je te suggérerai de "suivre le grain" de l'API.

describe "Both Fahrenheit" $ do
                it "same" $ do

c'est pas trés "beau", il serait plus logique d'avoir quelque chose du genre:

describe "Both Fahrenheit" $ do
                it "should be equal given same value" $ do
                it "should be different given different values" $ do

Mais encore une fois, l'exemple choisi se prêterait pas mal à l'utilisation de quickcheck.

Dans le code principal, je ne vois pas trop le problème que tu as avec ta classe: j'arrive à compiler ce code sans problème en rajoutant les flags qui vont bien (ghc me le dit...).

Je ne suis pas sûr non plus que l'utilisation intensive d'une notation "point-free" aide à la compréhension.... Surtout avec un pipeline de 10 fonctions. Je te suggérerai de détailler chaque partie de la fonction.

Une approche que j'aime bien utiliser et qui fonctionne bien en Haskell c'est de partir de la fonction principale qui ne fait rien, puis de la décomposer.


Cordialement,

--
Arnaud Bailly
FoldLabs Associate: http://foldlabs.com


2014-04-03 16:10 GMT+02:00 Gautier DI FOLCO <gautier.difolco@gmail.com>:
Le 3 avril 2014 11:00, Gautier DI FOLCO <gautier.difolco@gmail.com> a écrit :

Le 3 avril 2014 10:44, Sylvain Henry <hsyl20@gmail.com> a écrit :

Pour l'immutabilité, je montrerais les Lenses.

Bonne idée
 
Eviter d'utiliser des listes partout, notamment dans DayStmt, WeekStmt et MonthStmt, vu que le nombre de champs est fixe.

Pas forcément, tu ne peux avoir que les relevés de 40 jours par exemple, ce qui fais que tu as un mois et une semaine incomplète.
 
Utiliser des lenses ici serait pas mal, surtout pour réécrire la fonction finale. Si je comprends bien elle fait une sélection et une réduction, donc parfait avec des lenses.

 
Je ne suis pas convaincu par le Monoid, une simple fonction de réduction suffirait :
toStats :: [Temperature] -> Statistics
Là c'est compliqué inutilement je trouve.

Du coup tu perds la notion de groupes de relevés (jour, semaines, mois) et tu te retrouve à gérer le "conflit" °C/°F en même temps que le calcul des stats.

si je donne l'impression de vous rembarrer pour le plaisir, il n'en est rien, je tente juste d'exposer mes choix et de comprendre ce qui ne va pas (et j'ai l'impression de mal m'exprimer).
Le but c'est de montrer le TDD, il y a un aspect incrémental à mettre en valeur et arriver à quelque chose de complexe en partant de choses simple à mettre en valeur.
Le coding dojo en lui même n'est pas spécifiquement fonctionnel (je pense qu'on sera 3/20 à coder dans un langage fonctionnel, au sens large), mon but est de dire : la POO ne résout pas tout proprement, regardez en FP.
Je pense mes intentions sont plus claires.

_______________________________________________
Haskell-fr mailing list
Haskell-fr@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-fr