Существуют ли какие-либо особые проблемы для функционального программирования во встроенной среде?
Итак, я начинаю понимать, что отличает функциональное программирование от императивного программирования. Так что, как и любой хороший конвертер, я смотрю на вещи с молотом Хаскелла и пытаюсь представить, как мои встроенные работы по программированию могут быть сформированы как соответствующие гвозди для этого инструмента.
Итак, это заставило меня задуматься над этим вопросом. Является ли встроенная среда особым случаем общих вычислений в глазах функционального программирования или это просто другая форма общего случая? Является ли вызов всем в IO? Моя встроенная работа обычно включает около 90 - 95% периферийных операций ввода-вывода, а последнее немного вещей - это то, что работает алгоритм, который я могу поместить на него, и до сих пор вернусь к моему IO вовремя. Выполняет ли такая работа функциональную программу, не соответствующую моим потребностям?
Наконец, если есть какие-либо проекты для встроенных проектов Haskell, которые вы могли бы предложить, это было бы весьма полезно. Спасибо.
Ответы
Ответ 1
Существует целый ряд перспективных проектов по внедрению функционального программирования во встроенный мир программирования.
Похоже, что общий подход состоит в том, чтобы воспользоваться преимуществами безопасности и других функций корректности, но отказаться от суперсовременного исполнения, такого как ghc. В результате отказа от времени выполнения вы отказываетесь от таких функций, как сбор мусора. Вместо этого встроенные проекты Haskell используют встроенные языки DSL, которые выводят код C в реальном времени.
Встраиваемые проекты, использующие C-C, С++ и Haskell, вместо того, чтобы быть чистыми функциональными проектами. Код C, созданный кодом Haskell, не является идиоматическим кодом C, поэтому сотрудники проекта обычно должны быть знакомы с синтаксисом Haskell для участия.
Проект Галуа Копилота - это один из широкомасштабных документированных проектов Haskell.
http://corp.galois.com/blog/2010/9/22/copilot-a-dsl-for-monitoring-embedded-systems.html
Copilot использует Atom DSL, который кажется популярным
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/atom-0.0.2
Существует также умеренно активная группа Google
https://groups.google.com/forum/#forum/fp-embedded
Ответ 2
Лично я нашел Haskell.Atom совершенно не хватает. Это не функциональное программирование EDSL на функциональном языке. Вы ограничены конструкциями этого EDSL. Нет функций более высокого порядка, понимания списков и всех других вещей, которые делают функциональное программирование настолько лаконичным и приятным. Это может быть интересно для исключительно небольших проектов (например, мигание светодиода), но для меня кажется, что код, который вы пишете (не только сгенерированный C-код), будет экспоненциально увеличиваться по сравнению с функциональными возможностями, которые он предоставляет.
Если вы хотите пойти по функциональному маршруту, я предлагаю прочитать эту статью Малкольма Уоллеса. Он немного устарел, но, по крайней мере, он довольно подробно описывает, как делать низкоуровневые операции ввода-вывода, обработку IRQ и т.д. На чистом функциональном языке (Gofer, диалект Хаскелла).
Обновление: также существует совершенно новый исследовательский проект с целью создания функционального системного языка программирования на основе Haskell, Habit. К сожалению, он, по-видимому, существует в основном в теории.
