Sérieusement, il y a des gens qui pensent que ce genre de zigouigoui rend le code plus clair ? Pour un langage parlant (let … = in, match … with …), quelle idée de rajouter tous ses machines inexpressifs.([>, ~label, etc…)
Absolument ! Ca évite d'avoir a stocker les valeurs intermédiaires dans un calcul complexe.
Du genre:
Ose me dire que c'est moins lisible qu'une série de let…in imbriqués. :)
En plus, c'est assez facile de modifier la séquence de cas dans ces conditions puisque les fonctions ne sont pas dépendantes.
Pour ce qui est des énumérations, ca n'a rien a voir avec les types sommes (qui sont géniaux, par ailleurs).
Il s'agit de listes paresseuses infinies. Typiquement tu peux y mettre tous les naturels ou tous les entiers, puis faire des opérations de filtrage, et la parcourir a souhait en étant assuré que ton programme va terminer (si tu arrête ton parcours) et avec une faible empreinte mémoire.
La doc montre d'ailleurs comment résoudre un probleme Euler en trois lignes. ;-)
C'est un héritage de la Extlib 2, qui est maintenant abandonnée au profit de Batteries.
Et portable windows/unix ?
Il me semble que oui, après arriver a faire compiler Batteries sur Windows est possible mais c'est chiant. Faut en avoir le besoin.
Un code avec des listes est tellement plus lisible ! Est-ce que tu as réellement noté une augmentation de perf valable pour contre -balancer la lourdeur d'écriture ? J'ai l'impression que la collection doit être grosse (> 10 000 éléments) pour que cela soit intéressant.
Quand tu utilise des AVL ou des Rouge-Noir, c'est pas seulement pour des questions de rapidité mais aussi pour leurs propriétés intrinsèques.
Comme tu le dis, la syntaxe des listes est tres legere et l'API autour est tres fournie, mais tu te retrouve ensuite a adapter la logique de ton code a cette facilité.
En plus, clairement les arrays sont plus rapides et donnent moins de pression au GC, mais ce n'est pas tant pour les perfs que pour l'utilisation de la structure de donnée adaptée a ta manipulation. Si tu utilise ta liste comme une Queue, utiliser le module Queue augmente la lisibilité de ton code grandement meme s'il faut quelques characteres en plus.
[^] # Re: Surpris
Posté par mackwic . En réponse au journal Quelques projets intéressants en OCaml. Évalué à 3. Dernière modification le 01 mars 2013 à 19:42.
Absolument ! Ca évite d'avoir a stocker les valeurs intermédiaires dans un calcul complexe.
Du genre:
Ose me dire que c'est moins lisible qu'une série de let…in imbriqués. :)
En plus, c'est assez facile de modifier la séquence de cas dans ces conditions puisque les fonctions ne sont pas dépendantes.
Pour ce qui est des énumérations, ca n'a rien a voir avec les types sommes (qui sont géniaux, par ailleurs).
Il s'agit de listes paresseuses infinies. Typiquement tu peux y mettre tous les naturels ou tous les entiers, puis faire des opérations de filtrage, et la parcourir a souhait en étant assuré que ton programme va terminer (si tu arrête ton parcours) et avec une faible empreinte mémoire.
La doc montre d'ailleurs comment résoudre un probleme Euler en trois lignes. ;-)
C'est un héritage de la Extlib 2, qui est maintenant abandonnée au profit de Batteries.
Il me semble que oui, après arriver a faire compiler Batteries sur Windows est possible mais c'est chiant. Faut en avoir le besoin.
Quand tu utilise des AVL ou des Rouge-Noir, c'est pas seulement pour des questions de rapidité mais aussi pour leurs propriétés intrinsèques.
Comme tu le dis, la syntaxe des listes est tres legere et l'API autour est tres fournie, mais tu te retrouve ensuite a adapter la logique de ton code a cette facilité.
En plus, clairement les arrays sont plus rapides et donnent moins de pression au GC, mais ce n'est pas tant pour les perfs que pour l'utilisation de la structure de donnée adaptée a ta manipulation. Si tu utilise ta liste comme une Queue, utiliser le module Queue augmente la lisibilité de ton code grandement meme s'il faut quelques characteres en plus.