Application pratique de "Bananes, lentilles, enveloppes et barbelés"?

Question

Tout d'abord, le titre loufoque est directement référence à cet article:

http://eprints.eemcs.utwente.nl/7281/01/db-utwente-40501F46.pdf

Je comprends la valeur théorique de cela, comme il modélise la plupart, sinon la totalité, la sémantique de programmation.

Quels problèmes sont résolus le plus efficacement et pratiquement avec un paradigme de programmation basé sur cela? Quels problèmes ne sont pas? Imaginez des programmes entiers écrits où 80% de la logique impliquait ces opérateurs. Je me demande si un langage qui a forcé les opérateurs sur l'utilisateur pourrait tirer parti de leur structure ...

Answer 1

Cet article fait partie d'une longue série d'explorations théoriques connexes. Le domaine de recherche est ce que les programmeurs fonctionnels appellent la programmation générique (ce qui est confusément différent de ce que les programmeurs C++ appellent la programmation générique). L'idée est que vous écrivez vos fonctions de telle sorte que lorsque vous définissez un nouveau type de données, vous obtenez automatiquement le nouveau code pour l'accompagner. Un problème classique que les gens voudraient résoudre de cette façon consiste à écrire une image des données sur le disque et à relire plus tard les données isomorphes à partir de l'image du disque. Si vous voulez avoir une idée des applications pratiques de ces idées, je recommande l'excellent papier de Ralf Hinze Generics for the Masses, qui montre comment vous pouvez essayer toutes ces idées farfelues dans le vieux Haskell. Par exemple, j'ai utilisé ces techniques pour implémenter la capture-évitant la substitution de langages intermédiaires très compliqués dans les compilateurs.

Ralf a écrit un certain nombre de bonnes communications sur la programmation générique, tout comme Jeremy Gibbons. Leurs trucs ne sont pas aussi loin que les bananes, les lentilles, et ainsi de suite ...

Answer 2

Cela signifie que les solutions qui peuvent être modélisées dans un paradigme peuvent également être modélisées dans l'autre, et que l'on peut être converti par programme dans l'autre.

Maintenant, certains problèmes sont plus facilement résolus dans un paradigme que dans l'autre. En outre, il est plus facile de prouver les propriétés dans un paradigme que dans l'autre. Donc, si vous pouvez montrer une telle équivalence, vous ouvrez la porte à la résolution de certains problèmes dans le plus facile, puis la conversion de la solution dans le paradigme souhaité.

Ceci est similaire au mony thingy. Le gros problème avec les monades n'est pas comment en écrire un. Le gros problème avec eux est qu'il ya des tonnes de théorèmes sur les monades qui peuvent être appliquées une fois que vous réduisez votre problème à une monade. Le même principe s'applique ici.