Системное программирование в Haskell?

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

Ответы

Ответ 1

Сам Haskell ничего не делает, чтобы включить кодирование на системном уровне. Через интерфейс внешней функции (FFI) вы можете совершать вызовы в C/assembly, но здесь вы действительно просто передаете проблему другому языку.

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

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

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

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

class Monad m => MonadNetwork m where ...
class Monad m => MonadDiskDrive m where ...

Код, который должен использовать как сеть, так и дисковод, будет содержать ограничения, такие как

downloadToFile :: (MonadNetwork m, MonadDiskDrive m) => URL -> FilePath -> m ()

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

Такой API определенно заставит меня чувствовать себя более безопасным в отношении запуска кода из ненадежных источников, поскольку типы затем документируют (с тонкой детализацией), какие типы IO-ish, которые намеревается сделать код.

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

Ответ 2

Возможно ли это? Да В Haskell были операционные системы (см. House, LightHouse, hOp, ядро ​​L4, а также второе ядро ​​L4, созданное NICTA при разработке L4.verified), а также компоненты ОС низкого уровня (например: HALVM). Кроме того, вы можете написать модули Linux.

Эффективны ли здесь моноды? Монады - идиома программиста. Они не являются особым свойством ассемблерного кода, поэтому я не совсем понимаю, о чем вы спрашиваете. Что касается Haskell, то я бы сказал, что сложность рассуждений о пространственном использовании алгоритма является основной блокадой в работе модуля Linux, отчасти это связано с GC и отчасти из-за лени. Проблема немного усугубляется невозможностью проинформировать RH текущего контекста выполнения (для флажков kmalloc), но это действительно лаконичная деталь, которая может быть очищена и в настоящее время покрыта пессимистическими предположениями (GFP_KERNEL везде). Вы можете просмотреть мои слайды из модуля ядра, но знаете, что они были приглашены (ведущий), чтобы поговорить о некоторых моментах и ​​арендовать" т, сделанный в одиночку.

Ответ 3

В Haskell было множество низкоуровневых программных продуктов. См. http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system

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