Блок-схема функциональных языков программирования

Question

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

К сожалению, я вынужден создать блок-схему для моей программы (которая написана на Haskell).

Я полагаю, это легко для чего-то подобного:

main :: IO ()
main = do
   someInput <- getLine
   let upped = map toUpper someInput
   putStrLn upped

Это всего лишь 3 последовательных шага: выборка данных, их верхний регистр, вывод.

В этот раз все выглядит хуже:

main :: IO ()
main = do
   someInput <- fmap toUpper getLine
   putStrLn someInput

Или вот так:

main :: IO ()
main = interact (map toUpper)

Хорошо, это был IO, вы можете обращаться с этим как с императивным языком. А как насчет чистых функций?

Фактический пример:

onlyMatching :: String -> [FilePath] -> [FilePath]
onlyMatching ext = filter f
   where f name = lower ('.' : ext) == (lower . takeExtension $ name)
         lower  = map toLower

Как бы вы описали эту последнюю схему?

Answer 1

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

Но я думаю, что вы можете показать принципиальную схему (?).

        ext
       _ | ______________________________________________
      |  |                                               |
      |  `-> [ '.' : ] -------> [ lower ] --.__          |
      |                                      __ [ == ] ----->
name --> [ takeExtension ] ---> [ lower ] --'            |
      |__________________________________________________|
                              f

Вам лучше проконсультироваться с инструктором.

Answer 2

На самом деле, блок-схемы для использования в программном обеспечении датируются всего около 60 лет. (И действительно, программирование, как мы его знаем, датируется всего 65 лет!) В то время они были невероятно важны как инструмент для планирования и разработки алгоритмов до очень утомительного и подверженного ошибкам этапа «кодирования».

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

Однако, языки визуального программирования существуют и имеют большой успех в некоторых областях. Эти среды связаны с блок-схемами. Возможно, ваш инструктор действительно готовится выполнить некоторую сравнительную работу на языке программирования и побуждает вас задуматься об этих подходах.

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

Однако хитрость заключается в том, чтобы выяснить, как проиллюстрировать поток (частично примененных) функций в качестве данных. Подумайте о том, что должна делать блок-схема для поддержки концепции подпрограммы, которую можно вызывать в двух местах ... Теперь, возможно, вы можете создать аналогичную графическую конструкцию для обозначения "функции, идентифицируемой Ⓐ, в качестве второго аргумента filter «Я представляю себе небольшой лук с надписью fmap с вырезанным в стороне отверстием для ключа, чтобы Ⓐ можно было соединить стрелкой с.

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

Answer 3

Хм ... Вы можете вручную скомпилировать свой код в представление на основе суперкомбинаторов, а затем нарисовать диаграмму в виде блок-схемы этого приложения суперкомбинаторов. В некоторых случаях это даже полезно сделать, дает некоторое разумное визуальное представление потока. Просто подумайте о потоке данных, а не о потоке выполнения.

Answer 4

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

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

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