
J’ai fait un exercice de ce genre au Scala User Group il y a un ou deux ans: https://github.com/abailly/haskell-synthesizer
Ca introduit les types de données, la composition, la laziness (listes infinis) et même l’interaction avec le système, le tout dans un truc qui fait du bruit.
HTH
Arnaud
On 03 Apr 2014, at 16:10, Gautier DI FOLCO
Le 3 avril 2014 11:00, Gautier DI FOLCO
a écrit : Le 3 avril 2014 10:44, Sylvain Henry 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