Есть ли язык визуального моделирования или стиль для парадигмы функционального программирования?

Ответ 1

Мы используем теоретические указатели для формального моделирования (с проверкой), таких как Isabelle или Coq. Иногда мы используем языки, специфичные для домена (например, Cryptol), чтобы выполнить проект высокого уровня, прежде чем вывести реализацию Haskell с низким уровнем.

Часто мы просто используем Haskell в качестве языка моделирования и получаем фактическую реализацию путем перезаписи.

Свойства QuickCheck также играют определенную роль в документе разработки, а также разложения типов и модулей.

Ответ 2

Я считаю, что язык моделирования для Haskell называется " math". Это часто учили в школах.

Ответ 3

Да, в Haskell широко используются языки/методы моделирования/спецификации. Они не визуальные.

В Haskell типы дают частичную спецификацию. Иногда эта спецификация полностью определяет смысл/результат, оставляя различные варианты реализации. Выходя за пределы Haskell на языки с зависимыми типами, как в Agda и Coq (среди прочих), типы гораздо полезнее в качестве полной спецификации.

Если типов недостаточно, добавьте формальные спецификации, которые часто принимают простую функциональную форму. (Следовательно, я считаю, что ответы на язык моделирования для Haskell - это сам Haskell или "математика".) В такой форме вы даете функциональное определение, которое оптимизировано для ясности и простоты, а не для эффективности. Определение может включать даже бескомпромиссные операции, такие как равенство функций над бесконечными доменами. Затем, шаг за шагом, вы преобразовываете спецификацию в форму эффективно вычислимой функциональной программы. Каждый шаг сохраняет семантику (обозначение), и поэтому окончательная форма ( "реализация" ) гарантированно семантически эквивалентна исходной форме ( "спецификация" ). Вы увидите этот процесс, на который ссылаются различные имена, в том числе "преобразование программы", "деривация программы" и "расчет программы".

Шаги в типичном деривации - это в основном приложения "эквационального рассуждения", дополненные несколькими применениями математической индукции (и соиндукции). Способность выполнять такие простые и полезные рассуждения была главной мотивацией для языков функционального программирования в первую очередь, и они должны быть обоснованными "денотативным" характером "подлинно функционального программирования". (Термины "денотативные" и "действительно функциональные" взяты из оригинальной статьи Питера Ландина Следующие 700 языков программирования). Таким образом, крик сплочения для чистого функционального программирования был "хорош для эквациональных рассуждений", хотя я не слышал такого описания почти так же часто в эти дни. В Haskell денотативный соответствует типам, отличным от IO и типам, которые полагаются на IO (например, STM). В то время как денотативные/не IO типы хороши для правильного эквационального рассуждения, типы IO/non-denotative предназначены для плохого решения для эквационального мышления.

Конкретная версия деривации-из-спецификации, которую я использую как можно чаще в моей работе Haskell, - это то, что я называю "морфизмами семантического типа" (TCM). Идея состоит в том, чтобы дать семантику/интерпретацию для типа данных, а затем использовать принцип TCM для определения (часто уникального) значения большинства или всех функций типа с помощью экземпляров типа. Например, я говорю, что значение типа Image является функцией из 2D-пространства. Затем принцип TCM сообщает мне значения экземпляров Monoid, Functor, Applicative, Monad, Contrafunctor и Comonad, соответствующих тем экземплярам для функций. Это много полезной функциональности на изображениях с очень краткими и неотразимыми характеристиками! (Спецификация - это семантическая функция плюс список классов стандартного типа, для которых должен выполняться принцип семантического TCM.) И все же у меня есть огромная свобода представления изображений, а семантический принцип TCM устраняет утечки абстракции. Если вам интересно увидеть некоторые примеры этого принципа в действии, просмотрите документ Denotational design с морфизмами типа типа.

Ответ 4

Да, Хаскелл.

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

Ответ 5

Я просмотрел несколько видео-интервью и прочитал несколько интервью с такими, как erik meijer и simon peyton-jones. Похоже, что когда речь заходит о моделировании и понимании проблемной области, они используют сигнатуры типов, особенно сигнатуры функций.

Последовательные диаграммы (UML) могут быть связаны с составом функций. Статическая диаграмма классов (UML) может быть связана с сигнатурами типов.

Ответ 6

В Haskell вы моделируете по типам.

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

например. для моделирования сортировки:

class Ord a where
    compare :: a -> a -> Ordering

sort :: Ord a => [a] -> [a]
sort = undefined

тогда тесты

prop_preservesLength l = (length l) == (length $ sort l)
...

и, наконец, реализация...

Ответ 7

Хотя это не рекомендация использовать (поскольку она недоступна для загрузки), но HOPS system визуализирует графы сроков, которые часто являются удобным представлением функциональных программ.

Он также может считаться инструментом проектирования, поскольку он поддерживает документирование программ, а также их создание; Я полагаю, что он также может пройти через переписывание терминов, если вы хотите, чтобы вы могли видеть их развернуть.

К сожалению, я считаю, что он больше не активно развивается.

Ответ 8

Какой смысл в моделировании Haskell с Maths? Я думал, что весь смысл Хаскелла состоял в том, что он так тесно связан с математикой, что математики могли его поднять и побежать. Почему вы переводили язык в себя?

При работе с другим функциональным языком программирования (f #) я использовал диаграммы на белой доске, описывающей большие блоки, а затем смоделировал систему способом OO с использованием UML, используя классы. В строительных блоках в f # было небольшое совпадение (разбил классы на структуры данных и функции, которые действовали на них). Но для понимания с точки зрения бизнеса это работало. Я бы добавил, что проблема связана с бизнесом/веб-ориентированием и не знает, насколько хорошо техника будет работать для чего-то более финансового. Я думаю, что я, вероятно, захвачу функции как объекты без состояния, и они должны хорошо вписываться.

Все зависит от домена, в котором вы работаете.

Ответ 9

Я понимаю, что опаздываю на вечеринку, но я все равно дам свой ответ, если кто-то сочтет это полезным.

Думаю, я бы пошел на системные методологии вроде SADT/IDEF0.

• https://en.wikipedia.org/wiki/Function_model
• https://en.wikipedia.org/wiki/Structured_Analysis_and_Design_Technique

Такие диаграммы могут быть сделаны с помощью программы Dia, доступной как на Linux, Windows, так и на MacOS.

Ответ 10

Вы можете использовать сетевую модель процесса потока данных, как описано в Обработка сигналов в реальном времени: поток данных, визуальное и функциональное программирование Hideki John Reekie

Например, для кода типа (Haskell):

fact n | n == 0    = 1
       | otherwise = n * fact (n - 1)

Визуальное представление:

Ответ 11

Я использую USL - Universal Systems Language. Я изучаю Erlang, и я думаю, что это идеально подходит.

Слишком плохо, что документация очень ограничена, и никто ее не использует. Дополнительная информация здесь.