Różnica między State, ST, IORef i MVar

Ok, zacznę od IORef. IORef dostarcza wartość, która jest zmienna w MONADZIE IO. To tylko odniesienie do niektórych danych i jak każde odniesienie, istnieją funkcje, które pozwalają zmienić dane, do których się odnosi. W Haskell wszystkie te funkcje działają w IO. Możesz myśleć o tym jak o bazie danych, pliku lub innym zewnętrznym magazynie danych - możesz pobrać i ustawić w nim dane, ale wymaga to przejścia przez IO. Powodem, dla którego IO jest w ogóle konieczne, jest to, że Haskell jest pure ; kompilator potrzebuje sposobu, aby wiedzieć, do których danych odnosi się odniesienie w danym momencie(Czytaj sigfpe ' s "You could have invented monads" blogpost).

MVars są w zasadzie tym samym co IORef, z wyjątkiem dwóch bardzo ważnych różnic. {[3] } jest prymitywną współbieżnością, więc jest przeznaczona do dostępu z wielu wątków. Druga różnica polega na tym, że an MVar jest pudełkiem, które może być pełne lub puste. Więc gdzie an IORef Int zawsze ma Int (lub jest dnem), an MVar Int może mieć Int lub może być pusty. Jeśli wątek spróbuje odczytać wartość z pustego MVar, blokuje się do momentu wypełnienia MVar (przez inny wątek). Zasadniczo MVar a jest odpowiednikiem IORef (Maybe a) z dodatkowymi semantykami, które są przydatne dla współbieżności.

State jest monadą, która zapewnia stan zmienny, niekoniecznie z IO. W rzeczywistości jest to szczególnie przydatne dla czystych obliczeń. Jeśli masz algorytm, który używa stanu, ale nie IO, monada State jest często eleganckie rozwiązanie.

Istnieje również wersja monad transformer State, StateT. To często jest używane do przechowywania danych konfiguracyjnych programu lub typów stanu "game-world-state" w aplikacjach.

ST to coś nieco innego. Główną strukturą danych w ST jest STRef, która jest jak IORef, ale z inną monadą. Monad ST używa trickery type system ("wątki stanu", o których wspominają dokumenty), aby upewnić się, że zmienne dane nie mogą uciec z monad; oznacza to, że gdy uruchamiasz obliczenia ST, otrzymujesz czysty wynik. Powodem, dla którego ST jest interesujący jest to, że jest to prymitywna monada, taka jak IO, pozwalająca obliczeniom na wykonywanie niskopoziomowych manipulacji na bajtach i wskaźnikach. Oznacza to, że ST może zapewnić czysty interfejs podczas korzystania z niskopoziomowych operacji na zmiennych danych, co oznacza, że jest bardzo szybki. Z perspektywy programu, to tak, jakby obliczenia ST przebiegały w osobnym wątku z thread-local storage.

Inni zrobili podstawowe rzeczy, ale aby odpowiedzieć na bezpośrednie pytanie:

Wszystko to sprawia, że typ linii ENV = IORef [(String, IORef LispVal)] mylące. Dlaczego drugi IORef? Co? złamie się, jeśli zrobię type ENV = State [(String, LispVal)] zamiast tego?

Lisp jest językiem funkcjonalnym o zmiennym stanie i zasięgu leksykalnym. Wyobraź sobie, że zamknąłeś się przez zmienną. Teraz masz odniesienie do tej zmiennej wiszące wewnątrz jakiejś innej funkcji -- powiedzmy (w stylu Haskell pseudocode) (printIt, setIt) = let x = 5 in (\ () -> print x, \y -> set x y). Teraz masz dwie funkcje -- jeden drukuje x, a drugi ustawia jego wartość. Kiedy oceniasz printIt, chcesz wyszukać nazwę X w środowisku początkowym, w którym zdefiniowano printIt, ale chcesz wyszukać wartość , do której nazwa jest związana w środowisku, w którym printIt jest wywołane (po wywołaniu setIt może być wywołana dowolną ilość razy).

Są na to sposoby oprócz dwóch Iorefów, ale na pewno potrzebujesz czegoś więcej niż ten drugi typ, który zaproponowałeś, co nie pozwala Ci zmieniaj wartości, do których nazwy są związane w sposób leksykalny. Wygoogluj "funargs problem" dla wielu ciekawych prehistorii.