Czyste funkcjonalne programowanie w D

Question

Moim zdaniem moc funkcjonalnej czystości polega na tym, że głębokie ścieżki kodu można zweryfikować jako efekt uboczny. Jakie są doświadczenia ludzi w skali drzewa kodu, które mogą znajdować się w czystym specyfikatorze, a jaki poziom ponownego użycia kodu?

Kilka rzeczy dostrzegłem:

std.algorithm nie jest najczęściej oznaczone jako pure, ale potencjalnie może być w dużym stopniu czystości, albo czystej wersji algorytmów wymagających czystości funkcji instancji lub wstawek, albo przez czystości sam specyfikator jest statycznie polimorficzny.
Przydatne konwertery, takie jak to!string(someInt), nie są obecnie czyste.

elemencie zdefiniowane przez użytkownika wydaje się, że problem (jak pokazano poniżej) w:
1. czystych destruktory zagnieżdżonym struktury
2. czystej funkcji postblit nawet nie zagnieżdżonej struktury

Następujący kod obecnie daje wiele błędów na DMD 2.052 wygrać 32-bitowy

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' 

Answer 1

teoretycznie punkt pure D jest to, że powinien pozwolić gu zapewnia, że ​​dana funkcja jest darmowa bez względu na sposób implementacji tej funkcji. D Istnieją dwa rodzaje czystości:

• Wszystkie funkcje są słabo oznakowane pure czysty. Mogą nie mieć dostępu do globalnego stanu zmiennego (zmienne globalne, zmienne lokalne wątku, zmienne static itp.) Lub wykonać operacje wejścia/wyjścia. Mogą jednak mutować swoje argumenty. Celem tych funkcji jest to, że można je nazwać z bardzo czystych funkcji (opisanych poniżej) bez naruszania gwarancji silnej czystości.

• Wszystkie funkcje, które są słabo czyste i nie mają żadnych argumentów o zmiennym kierunku są bardzo czyste. Do tego celu można użyć konstruktorów typów const i. (W przypadku struktur i klas, wskaźnik this jest uważany za parametr.) Silnie czyste funkcje mają wszystkie miłe właściwości, o których mówią ludzie funkcjonalni, nawet jeśli są zaimplementowane przy użyciu stanu zmiennego. Silnie czysta funkcja zawsze zwraca tę samą wartość dla dowolnych argumentów i nie ma zauważalnych efektów ubocznych. Silnie czyste funkcje są relatywnie przezroczyste, co oznacza, że ​​ich wartość zwracana może zostać zastąpiona wywołaniem ich za pomocą danego zestawu parametrów bez wpływu na obserwowalne zachowanie. Każda silnie czysta funkcja może być bezpiecznie wykonywana równolegle z każdą inną mocno czystą funkcją.

Niestety oddziaływanie pomiędzy kodem ogólnej i pure (jak również const i immutable) jest raczej niska. Było kilka propozycji, aby to naprawić, ale żadna nie została jeszcze zaakceptowana.
\ std.algorithm jest napisany tak, aby był jak najbardziej ogólny, więc nie może wymagać, aby jego funkcje lambda i zakresy, które akceptuje, były czyste. Co więcej, funkcje systemu typów, które zostały dodane w D2, są na ogół najbardziej problematycznymi funkcjami w tym języku, ponieważ przed ustaleniem istotnych kwestii ustalono priorytetowe kwestie. Obecnie, pure zasadniczo nie nadaje się do użytku, z wyjątkiem banalnych przypadków, takich jak std.math.