Programmation de systèmes à Haskell?

Question

Est-il possible d'aller très bas niveau dans des langages fonctionnels comme Haskell? (comme faire un noyau ou un pilote de périphérique). Et les fonctions fonctionnelles (comme les monades) seront-elles rapides et efficaces?

Answer 1

Haskell lui-même ne fait rien pour activer le codage au niveau du système. Grâce à l'interface de fonction étrangère (FFI), vous pouvez passer des appels dans les sous-programmes C/assembly, mais vous ne faites qu'externaliser le problème dans une autre langue.

Le principal défi - et l'utilisation du FFI en est un signe avant-coureur - consiste à s'assurer que vous soutenez (et non gênez) le temps d'exécution. L'exécution de Haskell est (par nécessité) très complexe, en raison de la gestion automatique de la mémoire et de la gestion du code paresseux.

La gestion des interruptions est un problème classique du noyau/Haskell. Si une interruption intervient lorsque votre code Haskell est profondément dans le système d'exécution, vous ne serez pas en mesure de gérer l'interruption en temps opportun. Sur de nombreuses architectures, si un trop grand nombre d'interruptions sont mises en file d'attente avant d'être traitées, le matériel commet une erreur et s'arrête ou redémarre. Ce problème semble être le point central dans l'utilisation de Haskell au niveau du noyau.

Editer: Après réflexion, les monades peuvent être un idiome très utile dans le code au niveau des systèmes. Pensez à la façon dont IO est utilisé dans le code Haskell normal: c'est un contaminant de type type qui infecte des fonctions qui, bien, font des objets IO.

Étant donné que la programmation de systèmes concerne la gestion des ressources, il est souhaitable de savoir quel code interagit avec quelles ressources. On pourrait imaginer un transformateur monade pour chaque ressource en question, avec des fonctions spécifiques aux ressources extraites dans une classe de type. Par exemple, nous pourrions avoir

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

Code qui doit utiliser à la fois le réseau et le lecteur de disque procéderaient contraintes comme

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

Ceci est clairement un exemple de haut niveau (on ne s'attendre à trouver ceci dans un noyau), mais je pense que cela illustre l'idée. Ce serait certainement un moyen raisonnable d'exposer votre API OS à user-land, si cela ne vous dérangeait pas de rompre avec la tradition et d'avoir une API non-C (gasp). Une telle API me permettrait certainement de me sentir plus à l'aise d'exécuter du code provenant de sources non fiables, car les types documentent ensuite (avec une granularité fine) quelles sortes de choses IO-ish le code a l'intention de faire. Donc oui, je crois que les monades sont utiles dans la programmation au niveau des systèmes, pas pour des raisons d'efficacité, mais simplement parce que lorsque vous exécutez du code qui n'est pas dans un bac à sable, vous voulez connaître les intentions du code.

Answer 2

De nombreux logiciels de bas niveau ont été écrits dans Haskell. Voir http://www.haskell.org/haskellwiki/Applications_and_libraries/Operating_system

Les monades ne sont pas intrinsèquement efficaces ou inefficaces - cela dépend de la monade que vous utilisez et de la façon dont vous l'utilisez. Ce que vous voulez demander, ce sont des fonctions d'ordre supérieur (qui, soit dit en passant, sont tout ce dont vous avez besoin pour faire une monade). De nos jours, de nombreuses utilisations des HOF peuvent être compilées pour un code de bas niveau efficace.

Answer 3

Est-ce possible? Oui Il y avait des systèmes d'exploitation dans Haskell (voir House, LightHouse, hOp, un L4 kernel, et il y a un deuxième noyau L4 construit par NICTA lors du développement de L4.vérifié) ainsi que des composants OS de bas niveau (ex: HALVM). En outre, vous pouvez écrire Linux modules.

Les monades sont-elles efficaces ici? Les monades sont un idiome de programmeur. Ils ne sont pas une propriété particulière du code de l'assemblée, donc je ne comprends pas très bien ce que vous demandez. En ce qui concerne spécifiquement Haskell, je dirais que la difficulté de raisonner sur l'utilisation de l'algorithme dans l'espace est le blocus principal dans le travail du module Linux, ceci est en partie dû au GC et en partie à la paresse. Le problème est légèrement exacerbé par l'impossibilité d'informer le GHC RTS du contexte d'exécution actuel (pour les drapeaux de kmalloc), mais c'est vraiment un détail polonais qui peut être nettoyé et masqué par des hypothèses pessimistes (GFP_KERNEL partout). Vous pouvez consulter my slides à partir de l'effort du module Kernel, mais sachez qu'ils ont été créés pour m'inciter (le présentateur) à parler sur certains points et ne sont pas faits pour être autonomes.