Использование Haskell для значительных систем реального времени: как (если?)?

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

существует здоровый интерес к использованию Haskell или чего-то Haskell-подобного для компиляции до чего-то очень эффективного; например, Bluespec компилируется в оборудовании.

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

Андрей,

Да, это может быть сложно отлаживать проблемы через сгенерированный код обратно в исходный источник. Одна вещь, которую предоставляет Atom, - это средство зондирования внутренних выражений, а затем оставляет пользователю, как обращаться с этими зондами. Для испытания корабля, мы строим передатчик (в атоме) и пропускаем зонды вне над шиной консервной банки. Затем мы можем захватить эти данные, сформировать их, а затем просмотреть с помощью таких инструментов, как GTKWave, либо в пост-обработке, либо в реальном времени. Для программного обеспечения моделирование, зонды обрабатываются по-разному. Вместо того, чтобы получать данные зонда из протокола CAN, крючки сделаны в код C, чтобы поднять значения зонда напрямую. Значения зонда затем используются в структуре модульного тестирования (распределенной с Atom) для определения, проходит ли тест или не проходит, и для расчета покрытия моделирования.

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

запись в Atom-это не совсем программирование в Haskell, так как Haskell здесь можно рассматривать как чисто препроцессор для фактической программы, которую вы пишете.

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

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

я дурачился с атомом. Это довольно круто, но я думаю, что это лучше для небольших систем. Да, он работает в грузовиках и автобусах и реализует реальные, критические приложения, но это не означает, что эти приложения обязательно большие или сложные. Это действительно для жестких приложений в реальном времени и идет на многое, чтобы каждая операция занимала точно такое же количество времени. Например, вместо оператора if/else, который выполняет одну из двух веток кода может отличаться во времени выполнения, он имеет оператор "mux", который всегда выполняет обе ветви, прежде чем условно выбрать одно из двух вычисляемых значений (поэтому общее время выполнения одинаково, какое бы значение ни было выбрано). Он не имеет какой-либо значимой системы типов, кроме встроенных типов (сопоставимых с C), которые применяются через значения GADT, передаваемые через монаду атома. Автор работает над инструментом статической проверки, который анализирует выходной код C, что довольно круто (он использует SMT solver), но я думаю, что Atom выиграет от большего количества функций и проверок исходного уровня. Даже в моем игрушечном приложении (LED flashlight controller) я сделал ряд ошибок новичка, которых мог бы избежать кто-то более опытный с пакетом, но это привело к ошибочному выходному коду, который я бы предпочел поймать компилятор, а не через тестирование. С другой стороны, он все еще находится в версии 0.1.что-то такое, что улучшения, несомненно, грядут.