Est Haskell vraiment un rôle purement fonctionnel de la langue considérant unsafePerformIO?

Question

Haskell est généralement référencé comme un exemple d'un point de vue purement fonctionnel de la langue. Comment cela peut-il être justifié compte tenu de l'existence d' System.IO.Unsafe.unsafePerformIO ?

Edit: j'ai pensé à "l'aspect purement fonctionnel" il a voulu dire qu'il est impossible d'introduire impur code dans la partie fonctionnelle du programme.

Answer 1

Les Langues Que Nous Appelons Haskell

unsafePerformIO fait partie de la Étrangères de la Fonction de l'Interface de spécification, de base Haskell 98 cahier des charges. Il peut être utilisé pour faire des effets secondaires locaux qui n'échappent pas à une certaine étendue, dans le but d'exposer un point de vue purement fonctionnel de l'interface. C'est, nous l'utilisons pour masquer les effets lorsque le vérificateur de types peut pas le faire pour nous (à la différence de la ST monade, qui cache des effets statiques de garantie).

Pour illustrer précisément les multiples langues que nous appelons "Haskell", considérer l'image ci-dessous. Chaque anneau correspond à un ensemble spécifique de calcul de fonctions, commandé par la sécurité et de la zone correspondant à la puissance expressive (c'est à dire le nombre de programmes que vous pouvez écrire, si vous disposez de cette fonctionnalité).

La langue connue comme Haskell 98 est spécifié à droite vers le bas au milieu, en admettant totales et partielles de fonctions. Agda (ou Épigramme), où l'ensemble des fonctions sont autorisées, est encore moins expressif, mais "plus pur" et plus sûr. Tout en Haskell que nous l'utilisons aujourd'hui tout en œuvre pour les FFI, où unsafePerformIO vie. Qui est, vous pouvez écrire quelque chose de moderne, Haskell, mais si vous utilisez des choses à partir de l'extérieur des anneaux, il sera plus difficile d'établir la sécurité et des garanties de sécurité grâce à la bague intérieure.

Donc, Haskell programmes ne sont pas généralement construit à partir de 100% referentially code transparent, cependant, il est la seule modérément langue commune, qui est pure par défaut.

Answer 2

Je pensais que l'expression "purement fonctionnel" signifiait qu'il était impossible d'introduire du code impur...

La vraie réponse est que unsafePerformIO est no ne fait pas partie de Haskell, pas plus que le ramasse-miettes ou le système d'exécution ne font partie de Haskell. unsafePerformIO est présent dans le système afin que les personnes qui construisent le système puissent créer une abstraction fonctionnelle pure sur un matériel très efficace. Tous les langages réels présentent des lacunes qui permettent aux concepteurs de systèmes d'obtenir des résultats plus efficaces qu'en utilisant le code C ou le code d'assemblage.

En ce qui concerne la façon dont les effets de bord et les entrées-sorties s'intègrent dans Haskell par le biais de l'option IO monade, je pense que la façon la plus simple de penser à Haskell est qu'il s'agit d'un langage pur qui décrit des calculs efficaces. Lorsque le calcul décrit est main le système d'exécution exécute fidèlement ces effets.

unsafePerformIO est un moyen d'obtenir des effets d'une manière non sûre ; où "non sûr" signifie "la sécurité doit être garantie par le programmeur" - rien n'est vérifié par le compilateur. Si vous êtes un programmeur avisé et que vous êtes prêt à respecter de lourdes obligations en matière de preuve, vous pouvez utiliser unsafePerformIO . Mais à ce moment-là, vous ne programmez plus en Haskell, vous programmez dans un langage non sécurisé qui ressemble beaucoup à Haskell.

Answer 3

Le langage et la mise en œuvre sont purement fonctionnels. Il comprend quelques "trappes de secours", que vous n'êtes pas obligé d'utiliser si vous ne le souhaitez pas.

Answer 4

Je ne pense pas que unsafePerformIO signifie que haskell devienne impur d'une manière ou d'une autre. Vous pouvez créer des fonctions pures (référentiellement transparentes) à partir de fonctions impures.

Pensez à la liste de ski. Pour qu'elle fonctionne correctement, elle doit avoir accès à un RNG, une fonction impure, mais cela ne rend pas la structure de données impure. Si vous ajoutez un élément et que vous le convertissez ensuite en liste, la même liste sera renvoyée à chaque fois, compte tenu de l'élément que vous avez ajouté.

C'est pourquoi je pense que unsafePerformIO devrait être considéré comme promisePureIO. Une fonction qui signifie que les fonctions qui ont des effets secondaires et qui seraient donc qualifiées d'impures par le système de types peuvent être reconnues comme référentiellement transparentes par le système de types.

Je crois comprendre qu'il faut avoir une définition légèrement plus faible de pure pour que cela fonctionne, c'est-à-dire que les fonctions pures sont référentiellement transparentes et ne sont jamais appelées. parce que d'un effet secondaire (comme l'impression).

Answer 5

Malheureusement, le langage doit fonctionner dans le monde réel, ce qui implique de dialoguer avec l'environnement extérieur.

L'avantage est que vous pouvez (et devez) limiter l'utilisation de ce code "hors style" à quelques portions spécifiques et bien documentées de votre programme.