Programmation fonctionnelle - symboles standard, diagrammes, etc.

Question

J'ai un problème qui, à mon avis, serait mieux résolu par un style de programmation fonctionnel.

Venant d’un contexte très impératif, je suis habitué à concevoir des programmes comprenant des diagrammes / descriptions de classes, des diagrammes de communication, des diagrammes d’état, etc. Ces diagrammes impliquent tous, ou sont utilisés pour décrire, l’état d’un système et les divers effets secondaires que les actions ont sur le système.

Existe-t-il un ensemble normalisé de diagrammes ou de symboles mathématiques utilisé dans la conception de programmes fonctionnels ou est-il préférable de concevoir ces programmes en pseudo-code fonctionnel (étant donné que les fonctions seront beaucoup plus courtes que leurs homologues impératives).

Merci, Mike

Answer 1

Il existe un truc secret pour la programmation fonctionnelle.

1. Il est en grande partie apatride, les diagrammes impératifs traditionnels importent donc peu.

2. La plupart des notations mathématiques ordinaires utilisées dans les jardins sont également sans état.

La conception fonctionnelle ressemble plus à l’algèbre qu’à autre chose. Vous allez définir des fonctions et montrer que leur composition produit le résultat souhaité.

Les diagrammes ne sont pas aussi nécessaires car la programmation fonctionnelle est un peu plus simple que la programmation procédurale. Cela ressemble plus à la notation mathématique conventionnelle. Utilisez des techniques mathématiques pour montrer que vos diverses fonctions font le nécessaire.

Answer 2

Les programmeurs fonctionnels préfèrent écrire des équations que des diagrammes. Le jeu s’appelle raisonnement équationnel et implique principalement

• Substituer des égaux pour des égaux

• Application des lois algébriques

• La preuve occasionnelle par induction

L’idée est que vous écrivez un code très simple et "manifestement correct", puis que vous utilisez un raisonnement équationnel pour le transformer en quelque chose de plus propre et / ou qui fonctionnera mieux. Le maître de cet art est un professeur d'Oxford nommé Richard Bird.

Par exemple, si je souhaite simplifier l'expression de schéma

(append (list x) l)

Je remplacerai les égaux pour des égaux comme des fous. En utilisant la définition de list je reçois

(append (cons x '()) l)

Subtituer le corps de l'annexe I

(if (null? (cons x '())) 
    l
    (cons (car (cons x '())) (append (cdr (cons x '())) l)))

Maintenant, j'ai ces lois algébriques:

(null? (cons a b)) == #f
(car   (cons a b)) == a
(cdr   (cons a b)) == b

et en remplaçant les égaux par les égaux, je reçois

(if #f
    l
    (cons x (append '() l))

Avec une autre loi, (si #f e1 e2) == e2 , je reçois

(cons x (append '() l))

Et si j'utilise de nouveau la définition de append, je reçois

(cons x l)

que j'ai prouvé est égal à

<*>

Answer 3

• Ce très bon article explique le calcul lambda à l'aide d'animations: Pour disséquer un oiseau moqueur: une notation graphique pour le calcul lambda avec Réduction animée
• Celui-ci est très similaire au précédent, mais a une implémentation réelle: Animateur Lambda

Answer 4

Je ne connais pas grand chose à la programmation fonctionnelle, mais voici deux choses que j'ai rencontrées

• & # 955; (lambda) est souvent utilisé pour désigner un fonction
• f & # 959; g est utilisé pour indiquer la fonction composition