Czy jest jakiś powód, aby nie używać pragmy INLINABLE dla funkcji?

Dokumentacja stwierdza:

An {- #INLINABLE f #-} pragma na funkcji f ma następujące zachowanie:

• Podczas gdy INLINE mówi "please inline me", INLINABLE mówi "zapraszam do inline me; Użyj swojej dyskrecji". Innymi słowy wybór należy do GHC, który używa tych samych zasad co dla funkcji wolnych od pragmy. W przeciwieństwie do INLINE, decyzja ta jest podejmowana w miejscu wywołania, a zatem będzie miała wpływ na próg inlining, poziom optymalizacji itp.

• Podobnie jak inline, pragma INLINABLE zachowuje kopię oryginalnego RHS do celów inliningowych i utrzymuje ją w pliku interfejsu, niezależnie od rozmiaru RHS.

• Jednym ze sposobów użycia INLINABLE jest połączenie ze specjalną funkcją inline (sekcja 7.18, "specjalne wbudowane funkcje"). Aby upewnić się, że f może być wbudowany, dobrym pomysłem jest oznaczenie definicji f jako INLINABLE, dzięki czemu GHC gwarantuje odsłonięcie rozwijającego się niezależnie od jego wielkości. Co więcej, opisując f jako INLINABLE, upewniasz się, że oryginalny RHS f jest inlined, a nie dowolnie zoptymalizowana wersja optymalizatora F GHC.

• Pragma INLINABLE działa również z specialize: jeśli oznaczysz funkcję f jako INLINABLE, możesz następnie specjalizować się w innym module (patrz sekcja 7.16.8, "SPECIALIZE pragma").

• W przeciwieństwie do INLINE, można używać pragmy INLINABLE na funkcji rekurencyjnej. Głównym powodem tego jest umożliwienie późniejszego korzystania ze specjalizacji

Jaka jest tego wada?

Czy pliki interfejsu są znacznie większe? Czy to sprawia, że kompilacja jest znacznie wolniejsza?

Czy Jest jakiś powód, dla którego nie powinienem umieszczać pragmy INLINABLE na każdej wyeksportowanej funkcji, którą piszę? Czy jest jakiś powód, dla którego GHC nie umieszcza pragmy INLINABLE na każdej wyeksportowanej funkcji, którą piszę?