Функциональное программирование - стандартные символы, диаграммы и т. Д.

Question

У меня есть проблема, которую, я считаю, лучше всего решить с помощью функционального стиля программирования.

Исходя из очень императивного фона, я привык программировать дизайн с использованием диаграмм / описаний классов, диаграмм связи, диаграмм состояний и т. Д. Однако все эти диаграммы подразумевают или используются для описания состояния системы и различных побочные эффекты, которые действия оказывают на систему.

Существует ли какой-либо стандартизированный набор диаграмм или математических символов, используемых при разработке функциональных программ, или такие программы лучше всего разработаны в коротком функционально-псевдокоде (учитывая, что функции будут намного короче императивных аналогов).

Спасибо, Майк

Answer 1

Есть секретный трюк с функциональным программированием.

1. Это в значительной степени безгражданство, поэтому традиционные императивные диаграммы не имеют значения.

2. Большинство обычных математических обозначений для разных сортов также не имеют состояния.

Функциональный дизайн больше похож на алгебру, чем на что-либо еще. Вы собираетесь определить функции и показать, что композиция этих функций дает желаемый результат.

Диаграммы не так необходимы, потому что функциональное программирование несколько проще, чем процедурное программирование. Это больше похоже на обычные математические обозначения. Используйте математические методы, чтобы показать, что ваши различные функции делают правильные вещи.

Answer 2

Функциональные программисты больше пишут уравнения, чем пишут диаграммы. Игра называется эквациональное рассуждение и включает в себя

• Подставляя равно для равных

• Применение алгебраических законов

• Случайное доказательство по индукции

Идея состоит в том, что вы пишете действительно простой код, который «явно корректен», а затем вы используете эквациональные рассуждения, чтобы превратить его во что-то более чистое и / или более эффективное. Мастером этого искусства является профессор из Оксфорда по имени Ричард Берд.

Например, если я хочу упростить выражение схемы

(append (list x) l)

Я заменю равных на сумасшедших. Используя определение list, я получаю

(append (cons x '()) l)

Подстановка тела дополнения у меня

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

Теперь у меня есть эти алгебраические законы:

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

и подставляя равные для равных, я получаю

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

С другим законом, (if #f e1 e2) == e2, я получаю

(cons x (append '() l))

И если я добавлю определение добавления снова, я получу

(cons x l)

, которое я доказал, равно

(append (list x) l)

Answer 3

• Существует очень хорошая статья, объясняющая лямбда-исчисление с использованием анимаций: Чтобы расчленить пересмешника: графическая запись для лямбда-исчисления с анимированным сокращением
• Этот очень похож на предыдущий, но имеет реальную реализацию: Лямбда-аниматор

Answer 4

Я мало что знаю о функциональном программировании, но вот две вещи, с которыми я столкнулся

• λ (лямбда) часто используется для обозначения функция
• f o g используется для обозначения функции Состав