La documentation états:
Un {-# INLINABLE f #-} pragma sur une fonction f a le comportement suivant:
Si INLINE dit "s'il vous plaît inline-moi", le INLINABLE dit "se sentir libre pour inline moi; utilisez votre discrétion". En d'autres termes, le choix est laissé à GHC, qui utilise les mêmes règles que pour la pragma-gratuit fonctions. Contrairement à la volée, cette décision est prise sur le site d'appel, et seront donc concernés par l'alignement du seuil, optimisation etc niveau.
Comme INLINE, le INLINABLE pragma conserve une copie de l'original de l'ERS pour inline fins, et persiste, c'est dans le fichier d'interface, quelle que soit la taille de la RHS.
Une manière d'utiliser INLINABLE est en conjonction avec la fonction spéciale en ligne (Article 7.18, "Spécial intégré dans les fonctions"). L'appel inline f essaie très dur pour inline f. Pour vous assurer que f peut être inline, c'est une bonne idée pour marquer la définition de f, comme INLINABLE, de sorte que GHC garanties pour exposer un déroulement indépendamment de la façon dont il est grand. En outre, en annotant f comme INLINABLE, vous vous assurez que f est original RHS est inline, plutôt que quel que soit aléatoire version optimisée de la f GHC l'optimiseur a produit.
Le INLINABLE pragma travaille également avec d'SPÉCIALISÉES: si vous marquez la fonction f comme INLINABLE, alors vous pouvez par la suite se SPÉCIALISER dans un autre module (voir la Section 7.16.8, "se SPÉCIALISENT pragma").
Contrairement à la volée, c'est OK pour utiliser un INLINABLE pragma sur une fonction récursive. La principale raison à le faire pour permettre de les utiliser plus tard de se SPÉCIALISER
Quel est l'inconvénient de celui-ci?
Faut-il faire des fichiers d'interface beaucoup, beaucoup plus grand? Faire la compilation beaucoup plus lent?
Est-il une raison que je ne devrais pas mettre un INLINABLE pragma sur chaque fonction exportée-je écrire? Est-il une raison de GHC ne pas mettre un INLINABLE pragma sur chaque fonction exportée-je écrire?
