Ce qui est plus efficace à Haskell; correspondance de modèle ou instructions if / case imbriquées?

Question

Je suis simplement curieux de l’efficacité de l’appariement de modèles en Haskell. Quel est un cas simple où la correspondance de modèle serait meilleure que les instructions imbriquées / case et inversement?

Merci de votre aide.

Answer 1

Dans Haskell, case et la correspondance de modèle sont inextricablement liés. vous ne pouvez pas avoir l'un sans l'autre. si p alors e1 sinon e2 est le sucre syntaxique pour le cas p <{True - > e1; Faux - > e2} . Pour ces raisons, je pense qu'il est impossible de produire les exemples que vous demandez; dans Core Haskell, tout est équivalent à case .

Dans les langues de la famille ML, l’optimiseur peut souvent faire des choses très impressionnantes avec des correspondances de motifs complexes. C'est plus difficile pour les compilateurs Haskell; en raison d'une évaluation paresseuse, le compilateur de correspondance de motif n'est pas autorisé à réorganiser certains tests. En d'autres termes, si vous imbriquez les instructions case de différentes manières, vous obtiendrez peut-être des performances différentes, mais vous obtiendrez également une sémantique différente dans Haskell. Donc, généralement, le compilateur ne plaisante pas.

En ce qui concerne la manière d'écrire votre propre code, il est prudent de supposer que le code contenant le moins d'expressions de casse est le meilleur (en gardant à l'esprit qu'un si est équivalent à une expression de casse) .

Answer 2

Je n’ai pas confirmé cela, mais je pense que les deux formes deviendront une casse d’expression imbriquée lorsqu’elles seront traduites en noyau Haskell par le compilateur. La meilleure façon de le savoir est de demander au compilateur lui-même. Dans GHC, vous pouvez activer le dump du programme intermédiaire principal en utilisant les arguments suivants:

• Avant les simplifications: -ddump-ds
• Après les simplifications: -ddump-simpl

Answer 3

Selon la spécification, ils sont sémantiquement équivalent . Bien entendu, cela ne signifie pas nécessairement qu'elles sont implémentées de manière identique, mais je serais personnellement surpris de constater une différence entre un compilateur décent.