2011-04-28 56 views
22

在我看來,功能純度的強大之處在於深層代碼路徑可以被驗證爲無副作用。什麼是人們在代碼樹的規模上的經驗,它可以在純粹的說明符中,以及代碼重用的程度如何?D中的純函數式編程

有幾件事情,我看到:

std.algorithm大多沒有標記爲pure,但也可能是主要是純潔的,無論是通過算法苛刻的實體化功能或混入的純度純淨版,或者由純度說明符本身是靜態多態的。
有用的轉換器,如to!string(someInt)目前不是純粹的。

用戶定義的結構似乎有問題(如下面所示):
1.純析構函數在嵌套結構
2.即使在非嵌套結構

以下代碼純postblit功能目前給出了DMD 2.052多個錯誤贏得32位

struct InnerStruct 
{ 
    pure this(this) {} 
    pure ~this() {} 
} 

struct OuterStruct 
{ 
    InnerStruct innerStruct; 
    pure this(this) {} 
    pure ~this() {} 
} 

pure void somePureFunc() 
{ 
    OuterStruct s1 = OuterStruct(); // pure nested destructor does not compile 
    OuterStruct s2 = s1; 
    InnerStruct is1 = InnerStruct(); // pure non-nested destructor seems to compile 
    InnerStruct is2 = is1; // pure non-nested postblit does not compile 
} 

void main() 
{ 
    somePureFunc(); 
} 
pure_postblit.d(18): Error: pure function 'somePureFunc' cannot call impure function '__cpctor' 
pure_postblit.d(20): Error: pure function 'somePureFunc' cannot call impure function '__cpctor' 
pure_postblit.d(18): Error: pure function 'somePureFunc' cannot call impure function '~this' 
pure_postblit.d(17): Error: pure function 'somePureFunc' cannot call impure function '~this' 

回答

21

理論上的pure在d點是,它應該允許谷保證一個函數不管副作用如何實現,都是無副作用的。 D中有兩種純度:

  • 所有標記爲pure的功能都是弱純的。它們可能不會訪問任何全局可變狀態(全局變量,線程局部變量,static變量等)或執行I/O。但是,他們可能會改變他們的觀點。這些功能的要點是,它們可以從強純功能(下面詳述)調用,而不違反強純度的保證。

  • 所有功能弱純沒有任何參數與可變間接強烈純。可以使用constimmutable類型的構造函數來保證這一點。 (在處理結構和類時,指針this被認爲是一個參數。)強大的純函數具有函數式編程人員討論的所有優良屬性,即使它們是使用可變狀態實現的。強純函數總是爲任何給定的參數返回相同的值,並且沒有可觀察到的副作用。強純函數是引用透明的,這意味着它們的返回值可以用一組給定參數代替對它們的調用,而不影響可觀察到的行爲。任何強純函數都可以安全地與任何其他強純函數並行執行。

不幸的是通用代碼和pure(以及constimmutable)之間的相互作用是相當差的。有幾個提案可以解決這個問題,但還沒有人接受。
\ std.algorithm被寫成儘可能通用,因此它不需要它的lambda函數和它接受的範圍是純的。此外,在D2中添加的類型系統功能通常是該語言中性能最差的功能,因爲在解決相關問題之前已經優先考慮了更多基本事項。現在,pure基本上不可用,除了像std.math這樣微不足道的情況。

+0

感謝您的意見。 我注意到實驗時純度的弱定義,它顯然非常強大,允許在純代碼中進行完全可變的OO編程,並且在創建惰性評估thunk或調度promise等時,強大的形式可以很容易地被meta - 對類型限定符進行編程。我認爲,要實現高度併發的願景,還需要有更多能夠置身於純信封之中。我提到的析構函數和postblit問題對我影響最大,因爲我需要在純代碼中引用count,你認爲它們是錯誤嗎? – John 2011-04-28 19:19:06

+0

@John:是的,這些可能是錯誤的。 – dsimcha 2011-04-29 02:02:26