Programación de sistemas en Haskell?

Question

¿Es posible ir muy bajo nivel en lenguajes funcionales como Haskell? (como hacer un núcleo o un controlador de dispositivo). ¿Y las características funcionales (como las mónadas) serán rápidas y eficientes allí?

Answer 1

Haskell en sí no hace nada para habilitar la codificación de nivel de sistema. A través de la interfaz de función externa (FFI) puede realizar llamadas en C/rutinas de ensamblaje, pero aquí realmente solo está tercerizando el problema a otro idioma.

El desafío central, y el uso de FFI es un presagio de esto, es asegurarse de que está apoyando (y no obstaculizando) el tiempo de ejecución. El tiempo de ejecución de Haskell es (por necesidad) muy complejo, debido tanto a la administración automática de memoria como a la administración del código perezoso.

El manejo de interrupciones es un problema clásico de kernel/Haskell. Si aparece una interrupción cuando su código Haskell es profundo en el sistema de tiempo de ejecución, no podrá manejar la interrupción de manera oportuna. En muchas arquitecturas, si hay demasiadas interrupciones haciendo cola antes de ser manipuladas, el hardware dará error y se detendrá o se reiniciará. Este problema parece ser la clave central en el uso de Haskell en el nivel kernel.

Edit: En una reflexión más profunda, las mónadas pueden ser una expresión muy útil en el código de nivel de sistema. Piensa en la forma en que se usa IO en el código Haskell regular: es un contaminante a nivel de tipo que infecta las funciones que, bueno, hacen IO-cosas.

Dado que la programación de sistemas tiene que ver con la gestión de recursos, es conveniente rastrear qué código interactúa con qué recursos. Uno podría imaginar un transformador de mónada para cada recurso en cuestión, con funciones específicas de recursos abstraídas en una clase de tipo. Por ejemplo, podríamos tener

Código

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

que debe utilizar tanto la red como la unidad de disco llevarían limitaciones como

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

Esto es claramente un ejemplo de alto nivel (uno no esperaría encuentra esto en un kernel), pero creo que ilustra la idea. Sin duda, sería una forma razonable de exponer su API de sistema operativo a tierra de usuario, si no le importaba romper la tradición y tener una API (no de C).

Tal API definitivamente me haría sentir más seguro sobre la ejecución de código de fuentes no confiables, ya que los tipos luego documentan (con granularidad fina) qué tipo de cosas IO-ish intenta hacer el código.

Así que sí, creo que las mónadas son útiles en la programación a nivel de sistema, no por razones de eficiencia, sino simplemente porque cuando se ejecuta código que no está en una caja de arena, quiere saber las intenciones del código.

Answer 2

Ha habido numerosos programas de bajo nivel escritos en Haskell. Ver http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system

Las mónadas no son intrínsecamente eficientes ni ineficientes, sino que dependen de la mónada en particular que se esté utilizando y de cómo se use. Lo que quiere preguntar es sobre las funciones de orden superior (que, por cierto, es todo lo que necesita para hacer una mónada). En estos días, muchos usos de HOF se pueden compilar a un código eficiente de bajo nivel.

Answer 3

¿Es posible? Sí Ha habido sistemas operativos en Haskell (vea House, LightHouse, hOp, un L4 kernel, y hay un segundo kernel L4 construido por NICTA al desarrollar L4.verificado) así como componentes de bajo nivel del sistema operativo (por ejemplo, HALVM). Además, puede escribir Linux modules.

¿Las mónadas son eficientes aquí? Las mónadas son un modismo de programador. No son una propiedad especial del código ensamblador, así que no estoy muy seguro de lo que estás preguntando. Con respecto a Haskell, específicamente, diría que la dificultad de razonar sobre el uso del algoritmo en el espacio es el principal bloqueo en el trabajo del módulo de Linux, esto se debe en parte al GC y en parte a la pereza. El problema se ve un poco exacerbado por la imposibilidad de informar al GHC RTS del contexto de ejecución actual (para banderas kmalloc), pero ese es realmente un detalle pulido que puede limpiarse y cubrirse actualmente por suposiciones pesimistas (GFP_KERNEL en todas partes). Puede revisar my slides del esfuerzo del módulo Kernel, pero sepa que fueron hechos para solicitarme (el presentador) que hablen sobre ciertos puntos y que no están hechos para ser independientes.