GHC有一個「編譯指示」系統,允許您指定GHC的額外語言信息。特別是,它們看起來像
{-# <NAME> <ARGS...> #-}
,你會看到最常見的是語言擴展編譯指示其必須在文件的頂部,影響語言擴展在該文件的其餘部分的影響。
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Example where
通常情況下,應該是忽略編譯指示不會影響程序的含義。對於像INLINE
這樣的編譯指示來說,這大致如此,因爲它們僅僅是提示編譯器,爲了打開新的優化機會,該函數的主體應該被內聯到任何地方。 Haskell語義爲我們保證了這種內聯轉換何時不會改變程序的含義,因此編譯器選擇是否內聯對程序的意義沒有影響(只要它不違反這些保證的假設)。
LANGUAGE
pragmas有點不同,因爲它們指定文件的其餘部分準確寫入什麼語言。例如,我們通常假設的基本語言是Haskell98
或Haskell2010
和LANGUAGE
編譯指示添加擴展,使得早期的領導列舉的文件的語言是
Haskell2010 + RankNTypes + FlexibleInstances + ScopedTypeVariables
但除此之外暗示來的語言被寫入編譯這些雜注沒有更多的意義。
完整的允許編譯指示集取決於使用的編譯器。 GHC's pragmas are listed here(請注意,此鏈接適用於版本7.6.3,而註釋中的鏈接適用於7.0.3)。使用除LANGUAGE
以外的編譯指示可能會粗略且針對平臺,因此請認真學習它們的用法和含義。
例如,有大約庫作者是否應該使用INLINE
因爲它往往表明,在GHC自己的內聯啓發式缺乏信心,因此,我們應該花更多的精力收緊這些了,而不是亂拋垃圾代碼,一個大辯論手冊INLINE
s。但是,這說,如果明智地使用,INLINE
和INLINABLE
可以對嚴密的內循環產生深遠的影響。
文檔:http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/pragmas.html特別指出,試圖讓編譯器對函數進行內聯優化。 –