Quelles sont les règles concernant une fonction a -> () évaluée dans Haskell?

Tout comme le titre l'indique: quelles garanties existe-t-il pour qu'une unité de retour de fonction Haskell soit évaluée? On pourrait penser qu'il n'est pas nécessaire d'exécuter une sorte d'évaluation dans un tel cas, le compilateur pourrait remplacer tous ces appels par une ()valeur immédiate à moins que des demandes explicites de rigueur ne soient présentes, auquel cas le code pourrait avoir à décider s'il devrait retour ()ou bas.
J'ai expérimenté cela dans GHCi, et il semble que le contraire se produise, c'est-à-dire qu'une telle fonction semble être évaluée. Un exemple très primitif serait

f :: a -> ()
f _ = undefined

L'évaluation f 1renvoie une erreur en raison de la présence de undefined, donc une évaluation se produit définitivement. Cependant, la profondeur de l'évaluation n'est pas claire; parfois, il semble aller aussi loin qu'il est nécessaire d'évaluer tous les appels aux fonctions renvoyées (). Exemple:

g :: [a] -> ()
g [] = ()
g (_:xs) = g xs

Ce code boucle indéfiniment s'il est présenté avec g (let x = 1:x in x). Mais alors

f :: a -> ()
f _ = undefined
h :: a -> ()
h _ = ()

peut être utilisé pour montrer que les h (f 1)retours (), dans ce cas, toutes les sous-expressions unitaires ne sont pas évaluées. Quelle est la règle générale ici?

ETA: bien sûr, je connais la paresse. Je demande ce qui empêche les rédacteurs du compilateur de rendre ce cas particulier encore plus paresseux que d'habitude.

ETA2: résumé des exemples: GHC semble traiter ()exactement comme tout autre type, c'est-à-dire comme s'il y avait une question sur la valeur régulière occupant le type qui devrait être renvoyée par une fonction. Le fait qu'il n'existe qu'une seule de ces valeurs ne semble pas être (ab) utilisé par les algorithmes d'optimisation.

ETA3: quand je dis Haskell, je veux dire Haskell tel que défini par le rapport, pas Haskell-le-H-dans-GHC. Semble être une hypothèse qui n'est pas partagée aussi largement que je l'imaginais (qui était «à 100% des lecteurs»), ou j'aurais probablement pu formuler une question plus claire. Néanmoins, je regrette d'avoir changé le titre de la question, car elle demandait à l'origine quelles garanties existe pour une telle fonction appelée.

ETA4: il semblerait que cette question ait suivi son cours, et je la considère comme sans réponse. (Je cherchais une fonction de `` question proche '' mais je n'ai trouvé que `` répondre à votre propre question '' et comme il ne peut pas être répondu, je n'ai pas suivi cette voie.) Personne n'a soulevé quoi que ce soit du rapport qui déciderait de toute façon , que je suis tenté d'interpréter comme une réponse forte mais non définitive «aucune garantie pour la langue en tant que telle». Tout ce que nous savons, c'est que la mise en œuvre actuelle du GHC n'ignorera pas l'évaluation d'une telle fonction.

J'ai rencontré le problème réel lors du portage d'une application OCaml vers Haskell. L'application d'origine avait une structure mutuellement récursive de nombreux types, et le code a déclaré un certain nombre de fonctions appelées assert_structureN_is_correctN dans 1..6 ou 7, chacune renvoyant unité si la structure était effectivement correcte et lançant une exception si elle n'était pas . De plus, ces fonctions se sont appelées l'une l'autre en décomposant les conditions d'exactitude. À Haskell, cela est mieux géré en utilisant la Either Stringmonade, donc je l'ai transcrite de cette façon, mais la question en tant que problème théorique est restée. Merci pour toutes les contributions et réponses.

Vous semblez provenir de l'hypothèse que le type ()n'a qu'une seule valeur possible (), et vous vous attendez donc à ce que tout appel de fonction renvoyant une valeur de type ()soit automatiquement supposé produire effectivement la valeur ().

Ce n'est pas ainsi que Haskell fonctionne. Chaque type a une valeur de plus dans Haskell, à savoir aucune valeur, erreur ou soi-disant «bas», codé par undefined. Ainsi, une évaluation est en cours:

main = print (f 1)

est équivalent au langage Core

main = _Case (f 1) _Of x -> print x   -- pseudocode illustration

ou même ^(*)

main = _Case (f 1) _Of x -> putStr "()"

et Core de _Casese forçaient :

"L'évaluation d'une %case[expression] force l'évaluation de l'expression testée (le" candidat "). La valeur du candidat est liée à la variable suivant le %ofmot - clé, ...".

La valeur est forcée à une forme normale de tête faible. Cela fait partie de la définition du langage.

Haskell n'est pas un langage de programmation déclaratif .

^(*) print x = putStr (show x) et show () = "()", ainsi l' showappel peut être compilé complètement.

La valeur est en effet connue à l'avance comme (), et même la valeur de show ()est connue à l'avance comme "()". Toujours la sémantique Haskell accepté exigent que la valeur (f 1)est forcée à la tête forme normale faible avant d'imprimer celle connue dans la chaîne d'avance, "()".

modifier: Réfléchissez concat (repeat []). Cela devrait-il être []ou devrait-il être une boucle infinie?

La réponse d'un "langage déclaratif" à cela est très probablement []. La réponse de Haskell est, la boucle infinie .

La paresse est "la programmation déclarative du pauvre", mais ce n'est toujours pas la vraie chose .

edit2 : print $ h (f 1) == _Case (h (f 1)) _Of () -> print ()et seulement hest forcé, non f; et produire sa réponse hne doit rien forcer, selon sa définition h _ = ().

remarques d'adieu: La paresse peut avoir une raison d'être, mais ce n'est pas sa définition. La paresse est ce qu'elle est. Il est défini comme toutes les valeurs étant initialement des thunks qui sont forcées à WHNF en fonction des demandes en provenance main. S'il aide à éviter le fond dans un certain cas spécifique en fonction de ses circonstances spécifiques, il le fait. Sinon, non. C'est tout.

Cela aide à le mettre en œuvre vous-même, dans votre langue préférée, pour vous en faire une idée. Mais nous pouvons également retracer l'évaluation de toute expression en nommant soigneusement toutes les valeurs intermédiaires à mesure qu'elles se produisent.

D'après le rapport , nous avons

f :: a -> ()
f = \_ -> (undefined :: ())

puis

print (f 1)
 = print ((\ _ ->  undefined :: ()) 1)
 = print          (undefined :: ())
 = putStrLn (show (undefined :: ()))

et avec

instance Show () where
    show :: () -> String
    show x = case x of () -> "()"

il continue

 = putStrLn (case (undefined :: ()) of () -> "()")

Maintenant, la section 3.17.3 Sémantique formelle de correspondance de modèles du rapport dit

La sémantique des caseexpressions [est donnée] dans les figures 3.1 à 3.3. Toute implémentation doit se comporter de manière à ce que ces identités tiennent [...].

et le cas (r)dans la figure 3.2 états

(r)     case ⊥ of { K x1 … xn -> e; _ -> e′ } =  ⊥
        where K is a data constructor of arity n 

() est le constructeur de données de l'arité 0, il est donc le même que

(r)     case ⊥ of { () -> e; _ -> e′ } =  ⊥

et le résultat global de l'évaluation est donc ⊥.