Co to jest przejrzystość referencyjna?

Widziałem to w paradygmatach imperatywnych

f (x) + f (x)

może nie być taki sam jak:

2 * f (x)

Ale w paradygmacie funkcjonalnym powinno być tak samo. Próbowałem zaimplementować oba przypadki w Pythonie i Scheme , ale dla mnie wyglądają tak samo prosto.

Jaki byłby przykład, który mógłby wskazać różnicę w stosunku do danej funkcji?

Przezroczystość referencyjna, odnosząca się do funkcji, wskazuje, że wynik zastosowania tej funkcji można określić tylko na podstawie wartości jej argumentów. Możesz pisać referencyjnie przezroczyste funkcje w dowolnym języku programowania, np. Python, Scheme, Pascal, C.

Z drugiej strony, w większości języków możesz także pisać funkcje nie referencyjnie przejrzyste. Na przykład ta funkcja Pythona:

counter = 0

def foo(x):
  global counter

  counter += 1
  return x + counter

nie jest referencyjnie przejrzysty, w rzeczywistości dzwoni

foo(x) + foo(x)

i

2 * foo(x)

wygeneruje różne wartości dla każdego argumentu x. Powodem tego jest to, że funkcja używa i modyfikuje zmienną globalną, dlatego wynik każdego wywołania zależy od tego zmieniającego się stanu, a nie tylko od argumentu funkcji.

Haskell, język czysto funkcjonalny, ściśle oddziela ocenę wyrażeń, w której stosowane są funkcje czyste i która zawsze jest referencyjnie przejrzysta, od wykonania akcji (przetwarzanie wartości specjalnych), która nie jest referencyjnie przejrzysta, tj. Wykonanie tej samej akcji może mieć za każdym razem inny wynik.

Tak więc dla dowolnej funkcji Haskell

f :: Int -> Int

i dowolną liczbą całkowitą x, zawsze tak jest

2 * (f x) == (f x) + (f x)

Przykładem akcji jest wynik funkcji biblioteki getLine:

getLine :: IO String

W wyniku oceny wyrażenia ta funkcja (właściwie stała) przede wszystkim generuje czystą wartość typu IO String. Wartości tego typu są wartościami jak każda inna: możesz je przekazywać, umieszczać w strukturach danych, komponować je za pomocą specjalnych funkcji i tak dalej. Na przykład możesz zrobić listę takich akcji:

[getLine, getLine] :: [IO String]

Działania są wyjątkowe, ponieważ można powiedzieć środowisku wykonawczemu Haskell, aby je wykonał, pisząc:

main = <some action>

W takim przypadku, po uruchomieniu programu Haskell, środowisko wykonawcze przechodzi przez akcję związaną z nią maini wykonuje ją, prawdopodobnie powodując efekty uboczne. Dlatego wykonywanie akcji nie jest względnie przejrzyste, ponieważ dwukrotne wykonanie tej samej akcji może dać różne wyniki w zależności od tego, co środowisko wykonawcze otrzymuje jako dane wejściowe.

Dzięki systemowi typów Haskell nigdy nie można użyć akcji w kontekście, w którym oczekiwany jest inny typ, i odwrotnie. Jeśli więc chcesz znaleźć długość łańcucha, możesz użyć lengthfunkcji:

length "Hello"

zwróci 5. Ale jeśli chcesz znaleźć długość ciągu odczytywanego z terminala, nie możesz pisać

length (getLine)

ponieważ pojawia się błąd typu: lengthoczekuje wprowadzenia listy typów (a String jest rzeczywiście listą), ale getLinejest wartością typu IO String(akcja). W ten sposób system typów zapewnia, że ​​wartość akcji podobna getLine(której wykonanie odbywa się poza językiem podstawowym i która może być niereferencyjnie przezroczysta) nie może być ukryta wewnątrz wartości typu non-action Int.

EDYTOWAĆ

Aby odpowiedzieć na pytanie exizt, oto mały program Haskell, który odczytuje wiersz z konsoli i drukuje jego długość.

main :: IO () -- The main program is an action of type IO ()
main = do
          line <- getLine
          putStrLn (show (length line))

Główna akcja składa się z dwóch podgrup, które są wykonywane sekwencyjnie:

1. getlinetypu IO String,
2. drugi konstruuje się, oceniając funkcję putStrLntypu String -> IO ()na podstawie jej argumentu.

Dokładniej, druga akcja jest zbudowana przez

1. powiązanie linez wartością odczytaną przez pierwszą akcję,
2. ocena funkcji czystych length(oblicz długość jako liczba całkowita), a następnie show(zamień liczbę całkowitą na ciąg znaków),
3. budowanie akcji poprzez zastosowanie funkcji putStrLndo wyniku show.

W tym momencie można wykonać drugą akcję. Jeśli wpiszesz „Cześć”, wyświetli się „5”.

Zauważ, że jeśli otrzymujesz wartość z akcji za pomocą <-notacji, możesz użyć tej wartości tylko w innej akcji, np. Nie możesz napisać:

main = do
          line <- getLine
          show (length line) -- Error:
                             -- Expected type: IO ()
                             --   Actual type: String

ponieważ show (length line)ma typ, Stringpodczas gdy notacja wymaga, aby po akcji ( getLinetypu IO String) następowała kolejna akcja (np. putStrLn (show (length line))typu IO ()).

EDYCJA 2

Definicja przejrzystości referencyjnej Jörga W. Mittaga jest bardziej ogólna niż moja (poparłem jego odpowiedź). Użyłem ograniczonej definicji, ponieważ przykład w pytaniu koncentruje się na wartości zwracanej funkcji i chciałem zilustrować ten aspekt. Jednak RT ogólnie odnosi się do znaczenia całego programu, w tym zmian stanu globalnego i interakcji ze środowiskiem (IO) spowodowanych oceną wyrażenia. Tak więc, aby uzyskać poprawną, ogólną definicję, należy odnieść się do tej odpowiedzi.

def f(x): return x()

from random import random
f(random) + f(random) == 2*f(random)
# => False

Jednak nie to oznacza przejrzystość referencyjna. RT oznacza, że ​​możesz zastąpić dowolne wyrażenie w programie wynikiem oceny tego wyrażenia (lub odwrotnie) bez zmiany znaczenia programu.

Weźmy na przykład następujący program:

def f(): return 2

print(f() + f())
print(2)

Ten program jest względnie przejrzysty. Mogę wymienić jeden lub oba wystąpień f()z 2i nadal będzie ona działać tak samo:

def f(): return 2

print(2 + f())
print(2)

lub

def f(): return 2

print(f() + 2)
print(2)

lub

def f(): return 2

print(2 + 2)
print(f())

wszyscy będą zachowywać się tak samo.

Właściwie to oszukiwałem. Powinienem być w stanie zastąpić wywołanie do printwartością zwracaną (która w ogóle nie jest wartością) bez zmiany znaczenia programu. Jednak wyraźnie, jeśli po prostu usunę te dwie printinstrukcje, znaczenie programu ulegnie zmianie: wcześniej wypisał coś na ekranie, a potem nie. We / wy nie jest względnie przejrzyste.

Prosta zasada brzmi: jeśli możesz zastąpić dowolne wywołanie wyrażenia, podwyrażenia lub podprogramu wartością zwracaną tego wyrażenia, podwyrażenia lub wywołania podprogramu w dowolnym miejscu programu, bez zmiany jego znaczenia, wówczas masz odniesienie przezroczystość. A to oznacza, że ​​praktycznie nie możesz mieć żadnego wejścia / wyjścia, nie możesz mieć żadnego stanu zmiennego, nie może mieć żadnych skutków ubocznych. W każdym wyrażeniu wartość wyrażenia musi zależeć wyłącznie od wartości składowych wyrażenia. I w każdym wywołaniu podprogramu wartość zwracana musi zależeć wyłącznie od argumentów.

Części tej odpowiedzi pochodzą bezpośrednio z niedokończonego samouczka na temat programowania funkcjonalnego , hostowanego na moim koncie GitHub:

Mówi się, że funkcja jest referencyjnie przezroczysta, jeśli przy tych samych parametrach wejściowych zawsze daje takie same dane wyjściowe (wartość zwracana). Jeśli ktoś szuka racji bytu wyłącznie programowania funkcjonalnego, dobrym wyborem jest przejrzystość referencyjna. Podczas wnioskowania za pomocą formuł w algebrze, arytmetyce i logice, ta właściwość - zwana także substytucyjnością równości dla równości - jest tak fundamentalnie ważna, że ​​zwykle uważa się ją za coś oczywistego ...

Rozważ prosty przykład:

x = 42

W czysto funkcjonalnym języku lewa i prawa strona znaku równości są wzajemnie zastępowalne na oba sposoby. Oznacza to, że w przeciwieństwie do języka takiego jak C powyższa notacja naprawdę zapewnia równość. Konsekwencją tego jest to, że możemy rozumować o kodzie programu tak samo jak równania matematyczne.

Z Haskell wiki :

Czyste obliczenia dają tę samą wartość za każdym razem, gdy są wywoływane. Ta właściwość nazywa się przejrzystością referencyjną i umożliwia prowadzenie równego rozumowania w kodzie ...

Dla kontrastu, rodzaj operacji wykonywanej przez języki podobne do C jest czasami określany jako destrukcyjne zadanie .

Termin czysty jest często używany do opisania właściwości wyrażeń związanych z tą dyskusją. Aby funkcję można było uznać za czystą,

• nie wolno wykazywać żadnych skutków ubocznych, oraz
• musi być referencyjnie przejrzysty.

Według metafory czarnej skrzynki, znajdującej się w wielu podręcznikach matematycznych, elementy wewnętrzne funkcji są całkowicie odcięte od świata zewnętrznego. Efektem ubocznym jest sytuacja, gdy funkcja lub wyrażenie narusza tę zasadę - oznacza to, że procedura może w jakiś sposób komunikować się z innymi jednostkami programu (np. W celu udostępniania i wymiany informacji).

Podsumowując, przejrzystość referencyjna jest niezbędna, aby funkcje zachowywały się jak prawdziwe , matematyczne funkcje również w semantyce języków programowania.