Peux-tu lister les thèmes que tu souhaites aborder ? Et les lier aux parties de ton code ? J'ai du mal à voir la puissance du fonctionnel dans ton code. - Valentin 2014-04-02 14:50 GMT-07:00 Gautier DI FOLCO :

Le 2 avril 2014 23:22, vildric a écrit :

Si c'est pour des gens qui ne connaissent pas Haskell, tu ne devrais pas

...

utiliser la composition de fonction, c'est assez difficile de comprendre pour des non-initiés.

Ce n'est pas le but. Mes buts sont : 1. M'améliorer 2. Montrer la puissance du fonctionnel

Qu'ils ne comprennent pas chaque élément du code, ça, je m'y attends, qu'ils comprennent les idées globales et les idiomes quand je leur expliquerait, ça, c'est plus compliqué, mais du moment qu'ils en retiennent un, je suis content. Bref, je cherche à avoir le code le plus idiomatique possible.

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

Pour faire du TDD, je montrerais QuickCheck. Pour l'immutabilité, je montrerais les Lenses. Eviter d'utiliser des listes partout, notamment dans DayStmt, WeekStmt et MonthStmt, vu que le nombre de champs est fixe. 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. Sylvain Le 3 avril 2014 09:35, Gautier DI FOLCO a écrit :

Le 3 avril 2014 00:01, Valentin Robert a écrit :

Peux-tu lister les thèmes que tu souhaites aborder ? Et les lier aux

...

parties de ton code ?

En gros c'est un coding dojo TDD sur l'immutabilité. L'idée est de montrer à ceux qui font de la POO/impératif qu'ils n'ont pas besoin de "changer d'état" pour arriver à leurs fin. (Grosso-modo : mettre moins de POO et plus de fonctionnelle, ça fait un code plus beau) Typiquement, les points clefs : - TDD - Immutabilité - ValueObject (tiré de DDD) : l. 17 - 50 - Monoïdes : l. 56 - 78

J'ai du mal à voir la puissance du fonctionnel dans ton code.

...

dur

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

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.

Le 3 avril 2014 16:33, Arnaud Bailly a écrit :

Je ne vois pas trop la partie TDD, je trouve personnellement les tests peu expressifs.

Je pensais le faire vis-à-vis de la "distillation" des spécifications, je m'explique. J'ai un diaporama qui va contenir les instructions que je dévoilerais au fur et à mesure : - Les températures sont envoyées soit en °C soit en °F, la précision est d 'une décimale. * T(°C) = (T(°F) - 32)/1.8 * T(°F) = T(°C) * 1.8 + 32 - Les températures sont récoltées matin et soir et sont envoyées par ordre de récolte, en commençant par un matin. - On veut les statistiques suivantes pour toutes les valeurs reçues : Minimum / Maximum / Moyenne On veut le résultat en °F uniquement si toutes les valeurs sont en °F. - On veut ces statistiques uniquement pour les mesures du matin ou uniquement pour les mesures l'après midi. - On veut ces statistiques par semaine. - On veut ces statistiques par mois. - On veut ces statistiques par mois pour les lundi matin des semaines paires. L'idée est d'instaurer un certain rythme. 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.

J'ai un peu de mal à voir quelles propriétés tester.

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

Je plaide coupable, mais j'aurais le même problème de nommage avec RSpec.

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

Au moment de l'appel du programme via le shell ? J'utilise cabal, du coup je suppose que je dois regarder comment l'ajouter dedans.

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.

ok, mais le but n'est pas qu'ils comprennent l'intégralité de la fonction, toujours est-il que ça ne me coûte rien de le faire.

Peut être devrais-tu attendre un peu d'avoir un chouilla plus de bouteille. Pour l'instant je trouve que ca manque un peu de profondeur, que ca s'inscrit dans les discussions qu'on voit partout où on lit beaucoup de choses mais où il nous manque une vraie percée qui change notre perspective. Quand cela arrive, tu le sais, tu peux alors tout expliquer sans te poser de questions. Pour le coup, l'auteur de hspec est un de mes coworkers, et il y a quelques jours il a fait un mini talk à l'équipe où il parlait de TDD en haskell précisément. Et oui il faut parler des libs centrales, certaines avec des idées si intéressantes qu'elles ont fait l'objet de papers. Il faut parler de pureté aussi, et aussi de comment ca se rattache aux types (plus un type est abstrait, moins tu peux te reposer sur ses spécificités, moins il y a d'implémentations possibles, plus il y a de chances que ton code soit correct par construction, i.e juste par le fait qu'il typecheck, en gros la façon dont Edward Kmett écrit ses libs -- et là tu ne fais plus du TDD même si on a en général quand même des tests mais ils ont une place moins importante). En gros je pense que pour démontrer des choses sur tout ca en Haskell, il faut avoir une bonne idée de la vue globale, et que du coup ca demande un certain temps. Si tu te sens assez à l'aise avec tout ça fonce, mais sinon j'ai peur que tu leur montres juste limite "une autre syntaxe" pour faire des tests et qu'ils verront juse ça comme quelqu'un qui présente les trucs cools de son langage. Alors que je pense vraiment que Haskell a d'énormes longueurs d'avance sur pleins de sujets, et c'est parce qu'on pense tous ça dans mon équipe que l'on s'est lancé dans un sacré défi :) Le 3 avr. 2014 16:10, "Gautier DI FOLCO" a écrit :

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

Continue de persévérer. 6 ans après mes débuts il y a toujours des bouts de code que je ne pige qu'après plusieurs heures/jours. Bon courage pour le dojo. Le 3 avr. 2014 19:52, "Gautier DI FOLCO" a écrit :

Le 3 avril 2014 18:19, Alp Mestanogullari a écrit :

...

Peut être devrais-tu attendre un peu d'avoir un chouilla plus de bouteille.

oui et non. oui, je suis clairement au début du chemin, je le sais, mais non, je ne peux pas attendre, tout est prévu, plus moyen de reculer.

...

Pour l'instant je trouve que ca manque un peu de profondeur, que ca s'inscrit dans les discussions qu'on voit partout où on lit beaucoup de choses mais où il nous manque une vraie percée qui change notre perspective. Quand cela arrive, tu le sais, tu peux alors tout expliquer sans te poser de questions.

J'en suis conscient, c'est une des choses qui m'a poussé à "arrêter" l'animation. Le soucis c'est que cette percée, je n'ai pas pu la faire en lisant un grand nombre de documents sur le sujet, du coup il me faut de la pratique et beaucoup de temps. Faute de mieux, pour le moment, je me fais la main là dessus.

...

Il faut parler de pureté aussi, et aussi de comment ca se rattache aux types (plus un type est abstrait, moins tu peux te reposer sur ses spécificités, moins il y a d'implémentations possibles, plus il y a de chances que ton code soit correct par construction, i.e juste par le fait qu'il typecheck, en gros la façon dont Edward Kmett écrit ses libs -- et là tu ne fais plus du TDD même si on a en général quand même des tests mais ils ont une place moins importante).

C'est là où je sèche et où je sais que le sécherais tant que je ne me saurais pas pris assez de "coups".

...

En gros je pense que pour démontrer des choses sur tout ca en Haskell, il faut avoir une bonne idée de la vue globale, et que du coup ca demande un certain temps.

Je suis de ton avis et je sais que ça n'est pas mon cas.

...

Si tu te sens assez à l'aise avec tout ça fonce, mais sinon j'ai peur que tu leur montres juste limite "une autre syntaxe" pour faire des tests et qu'ils verront juse ça comme quelqu'un qui présente les trucs cools de son langage.

Non, je ne suis pas à l'aise, pas suffisamment du moins. J'ai la prétention de présenter légèrement plus qu'une autre syntaxe pour le programme principal, pour les tests, ça reste très très proche de RSpec, donc rien de neuf.

...

Alors que je pense vraiment que Haskell a d'énormes longueurs d'avance sur pleins de sujets, et c'est parce qu'on pense tous ça dans mon équipe que l'on s'est lancé dans un sacré défi :)

Je le pense aussi.

Encore une fois, mon but personnel est d'en apprendre le maximum possible, mon but pour le coding dojo est "juste" de leur dire : voilà un cas que le FP gère bien, voilà comment on le ferait de manière idiomatique en FP.

Je ne l'ai pas fait depuis le début, mais merci de prendre de votre temps pour moi, je suis plus que conscient de mes limites et de la route qu'il me reste à parcourir, je sais que rien ne me sera offert sur un plateau (ça n'a jamais été le cas et j'espère que ça ne le sera jamais) et que vous n'allez pas résoudre tout mes problèmes en un coup de baguette magique. Merci encore, toutes vos remarques confirment mes intuitions (même si ça ne se voit pas aux vues de mes actes/mon code, je pense que j'ai encore du mal à sortir de ma zone de confort, même si je fais tout pour) et me stimulent encore plus pour continuer. TL;DR : merci

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

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

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

En fait je pensais expliciter les noms des champs pour tes structures : data DayStmt = DayStmt { _morning, _evening :: Temperature} data WeekStmt = WeekStmt { _monday, _tuesday, ..., _sunday :: DayStmt} etc. Après du coup tu peux composer tes lenses pour aller chercher les champs qui t'intéressent : monday . evening En composant un peu tu devrais pouvoir faire des "requêtes" sympas dans ton ensemble de temperatures. Le 4 avril 2014 15:06, Gautier DI FOLCO a écrit :

Le 3 avril 2014 10:44, Sylvain Henry a écrit :

...

Si je comprends bien elle fait une sélection et une réduction, donc parfait avec des lenses.

J'ai fais une tentative, mais le gain est nul, je dois me débarrasser des map si je suis ton raisonnement, mais je n'ai pas trouvé de fonctions pour, tu aurais des pointeurs/exemples ?

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

Le 4 avril 2014 18:31, Gautier DI FOLCO a écrit :

Le 4 avril 2014 17:00, Sylvain Henry a écrit :

En fait je pensais expliciter les noms des champs pour tes structures :

...

data DayStmt = DayStmt { _morning, _evening :: Temperature} data WeekStmt = WeekStmt { _monday, _tuesday, ..., _sunday :: DayStmt} etc.

Après du coup tu peux composer tes lenses pour aller chercher les champs qui t'intéressent : monday . evening

En composant un peu tu devrais pouvoir faire des "requêtes" sympas dans ton ensemble de temperatures.

Oui, je vois, mais comment tu fais quand tu n'as pas de jours/semaines/mois complets ? foutre des Maybe partout est un peu lourd, non ?

Bonjour, J'ai (je pense) pas mal bossé à tous les niveaux (tests + implantations). Du coup je suis plus partie pour faire un DSEL-like et quelque chose de plus type-safe. Je suis assez content de moi, sauf pour les make*Stmt (l.74 - l.78 - l.82), je pense que ça mériterait l'usage de monades à ce niveau. Du coup, quelques petites questions : - est-ce plus "profond" ? - est-ce plus idiomatique ? - quels sont les points à améliorer ? - que pensez-vous de mon problème de make (ci-dessus) ? (est-ce réellement un problème ? est-ce comme ça que vous le résoudriez ? si non, comment ?) j'ai fait une tentative infructueuse avec les Applicatives - que penseriez de passer une fonction de regroupement ? (pour éviter les weeklyStats/monthyStats) ? - j'utilise finalement peu les Lenses, ne fais-je pas mieux de les virer ? ou y a-t-il un moyen pour que j'en tire partie ? Merci par avance.

Le 6 avril 2014 18:09, Arnaud Bailly a écrit :

Première réaction à chaud: - les tests sont nettement plus sympas, compréhensibles et utiles (je comprends à quoi sert la lib grâce à eux

:)

- pour utiliser les lens, voici ce que fait cabal: Resolving dependencies... Downloading transformers-compat-0.1.1.1... Downloading tagged-0.7.1... Configuring tagged-0.7.1... Configuring transformers-compat-0.1.1.1... Building transformers-compat-0.1.1.1... Building tagged-0.7.1... Installed transformers-compat-0.1.1.1 Installed tagged-0.7.1 Downloading contravariant-0.4.4... Downloading distributive-0.4.3.1... Configuring contravariant-0.4.4... Configuring distributive-0.4.3.1... Downloading reflection-1.4... Configuring reflection-1.4... Building contravariant-0.4.4... Building reflection-1.4... Installed contravariant-0.4.4 Building distributive-0.4.3.1... Installed reflection-1.4 Installed distributive-0.4.3.1 Downloading comonad-4.0.1... Configuring comonad-4.0.1... Building comonad-4.0.1... Installed comonad-4.0.1 Downloading semigroupoids-4.0.1... Configuring semigroupoids-4.0.1... Building semigroupoids-4.0.1... Installed semigroupoids-4.0.1 Downloading bifunctors-4.1.1... Downloading profunctors-4.0.3... Configuring bifunctors-4.1.1... Configuring profunctors-4.0.3... Building bifunctors-4.1.1... Building profunctors-4.0.3... Installed profunctors-4.0.3 Installed bifunctors-4.1.1 Downloading free-4.6.1... Configuring free-4.6.1... Building free-4.6.1... Installed free-4.6.1 Downloading lens-4.1.2... Configuring lens-4.1.2... Building lens-4.1.2... Installed lens-4.1.2

Est-ce vraiment nécessaire ?

Je pensais qu'on ne pouvait pas l'éviter, je vais voir, meci.

Par ailleurs dans le code, je ne suis pas du tout convaincu par les méthode mlxxx, elles sont assez illisibles.

make*Stmt je suppose, si oui, je suis de ton avis, mais je ne vois pas comment les simplifier :/

Bravo pour les améliorations en tout cas.

Merci, ça me touche.

Ce n’est pas le fait qu’il fasse ça qui me pose problème, c’est la flopée de dépendances que tirent les lens pour un usage très limité dans ton code. Pour faire une analogie avec ce que je vis au quotidien, c’est comme utiliser spring+hibernate pour faire un select dans une base… Arnaud On 06 Apr 2014, at 18:01, Gautier DI FOLCO wrote:

Le 4 avril 2014 18:31, Gautier DI FOLCO a écrit : Le 4 avril 2014 17:00, Sylvain Henry a écrit :

En fait je pensais expliciter les noms des champs pour tes structures : data DayStmt = DayStmt { _morning, _evening :: Temperature} data WeekStmt = WeekStmt { _monday, _tuesday, ..., _sunday :: DayStmt} etc.

Après du coup tu peux composer tes lenses pour aller chercher les champs qui t'intéressent : monday . evening

En composant un peu tu devrais pouvoir faire des "requêtes" sympas dans ton ensemble de temperatures.

Oui, je vois, mais comment tu fais quand tu n'as pas de jours/semaines/mois complets ? foutre des Maybe partout est un peu lourd, non ?

Bonjour,

J'ai (je pense) pas mal bossé à tous les niveaux (tests + implantations). Du coup je suis plus partie pour faire un DSEL-like et quelque chose de plus type-safe. Je suis assez content de moi, sauf pour les make*Stmt (l.74 - l.78 - l.82), je pense que ça mériterait l'usage de monades à ce niveau. Du coup, quelques petites questions : - est-ce plus "profond" ? - est-ce plus idiomatique ? - quels sont les points à améliorer ? - que pensez-vous de mon problème de make (ci-dessus) ? (est-ce réellement un problème ? est-ce comme ça que vous le résoudriez ? si non, comment ?) j'ai fait une tentative infructueuse avec les Applicatives - que penseriez de passer une fonction de regroupement ? (pour éviter les weeklyStats/monthyStats) ? - j'utilise finalement peu les Lenses, ne fais-je pas mieux de les virer ? ou y a-t-il un moyen pour que j'en tire partie ?

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

Le 6 avril 2014 19:39, Gautier DI FOLCO a écrit :

Le 6 avril 2014 19:35, Arnaud Bailly a écrit :

Ce n'est pas le fait qu'il fasse ça qui me pose problème, c'est la flopée

...

de dépendances que tirent les lens pour un usage très limité dans ton code. Pour faire une analogie avec ce que je vis au quotidien, c'est comme utiliser spring+hibernate pour faire un select dans une base...

C'est une de mes questions, aux vues de l'usage que j'en ai, n'ais-je pas meilleur compte à les retirer ? ou bien y a-t-il une fonctionnalité qui puisse me servir pour améliorer mon code ?

Si je peux ajouter une question : je dois gérer pas mal de Maybe, je ne trouve pas ça bien propre, y a-t-il une manière de faire plus élégante ?

J'ai viré les Lenses, mais ça reste sale.

Le 6 avril 2014 22:01, Arnaud Bailly a écrit :

Pour les maybe peut-être serait-il plus élégant d'intégrer directement un constructeur "vide" dans chacun de tes types ? Tu perds le catMaybes met tu peux avoir une fonction qui filtre sur l'absence, c'est pas beaucoup plus compliqué.

Tu veux un GADT, du style : data DayStmt = NoDayTemp | MorningDayTemp Temperature | EveningDayTemp Temperature | FullDayTemp Temperature Temperature par contre je ne vois pas l'enchaînement qui en découlerait.

Te représentation des types Week et Month n'est peut-être pas idéal. Pourquoi ne pas avoir directement une liste de jours/semaines ? Pas sûr qu'avoir des champs pour les noms de jours et les numéros de semaine apporte grand-chose à l'histoire (et puis tu fais des suppositions sur le premier jour de la semaine qui est le dimanche dans les pays "anglo-saxons" par exemple)...

C'est ce que j'avais au début, mais le nommage est mieux je trouve, c'est plus explicite. Pour Week et Month, c'est juste que je voulais un contrôle des types au début (que ne m'aurais pas apporté type), puis par la suite ça m'a permit de nommer les champs. Si on va par là, les mois n'ont pas tous 28 jours et les mois ne commencent pas toujours par un lundi (ou un dimanche), mon but est de fournir un cadre permettant d'avoir un code assez simple, gérer correctement les dates rajouterait pas mal de complexité à mon sens. Je suis arrivé à introduire un Monoid assez pertinent à mon sens (mais corrigez moi si je me trompe), du coup je suis assez content. Je négocie mais n'hésitez pas si vous avez des remarques :)