Подтвердить что ты не робот

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

блок-схемы. Эта древняя старая практика, которая использовалась уже более 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

Как бы вы проиграли последнюю?

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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