🚀 go-pugleaf

Paweł 'Pasza' Ostrowski napisał:
>> Czy może ktoś z Was ma jakąś intuicję dotyczącą samego pojęcia monady
>> jak i operatora >>=? Tak na chłopski rozum ;)
> 
> Hmm - tak jak pisałem, sam dopiero zacząłem to czuć (przeczytałem
> właśnie gentle introduction to haskell i jeszcze takie coś:
> http://www.abercrombiegroup.co.uk/~noel/research/monads.html), więc
> mogę trochę gadać głupoty - niech mnie ktoś w razie czego poprawi,
> pójdę się wtedy douczać dalej.
> 
> Monada: polimorficzny typ (czyli sparametryzowany innym typem), np
>         data Maybe a = Just a | Nothing, na którym zdefiniowane są
>         operatory klasy Monad (czyli właśnie >>=, return, >>, może coś
>         jeszcze).

Dokładnie -> unarny konstruktor typu.

Jest jeszcze 
    fail :: Monad m => String -> m a
która to funkcja konstruuje obliczenie - porażkę, oczywiście w sposób
zależny od typu monady, np. w IO jest to rzucenie wyjątku, w [] lista
pusta, a w Maybe poprostu Nothing.

>	  Ważna jest chyba monada stanowa (koniecznie zobacz
>         przykłady w obu źródłach które podałem), rozwiązuje ona
>         problem stanu w programie funkcyjnym.

Monady pozwalają opisać wiele "efektów", np.
    - stan
    - wyjątki (Maybe, IO, Either)
    - niedeterminizm (choćby monada [])
    - referencje mutowalne (IO, ST s)
    - tablice mutowalne (IO, ST s)
    - wejście / wyjście (IO)
    - wątki (co ciekawe można wymodelować ograniczoną postać wątków w 
	     czystym Haskellu, bez wsparcia środowiska wykonawczego)
    - kontynuacje
    - środowisko

W hugsie i GHC są biblioteki transformatorów monad, z których można
uzyskać monady z różnymi kombinacjami efektów. Nie licząć IO i Maybe
osobiście znalazłem zastosowanie dla monad stanu, kontynuacji i pisarza
(Writer), oraz dla monad z bibliotek WASH i Parsec (bardzo ciekawy
przykład - monada parsowania).

>	  Dzięki takiej
>         konstrukcji np. operacje wejścia/wyjścia, czy wogóle
>         jakiekolwiek ze skutkami ubocznymi mogą być funkcjami (czyli
>         zależeć tylko od swoich argumentów, a nie od środowiska),
>         ponieważ środowisko przekazujemy w jednym z parametrów. Tego
>         środowiska nie można wyciągnąć w żaden sposób boza monadę,
>         obliczenia na nim są zaszyte w kokretną definicję operatora
>         >>=.

W monadach IO i ST jest to konieczność, ale nie wszystkie monady są
abstrakcyjne i zabraniają dostępu do swojej reprezentacji.

>>>= : typ jest taki :: M a -> (a -> M b) -> M b, czyli bierzemy monadę
>       opartą o typ a, wyciągamy z niej wartość (tego typu a) i
>       przekazujemy ją do funkcji, która na podstawie tego a da nam
>       monadę M b. Ta funkcja (a -> M b) służy przekazaniu wyniku
>       obliczenia z tej poprzedniej monady do następnej (można go użyć
>       w dalszych obliczeniach). Sam operator >>= (bind), według mojego
>       wyczucia, składa kolejne wyniki obliczenia, w końcu dostajemy
>       funkcję, która po zaaplikowaniu do wartości typu a pierwszego
>       typu (M a) da wynik przejścia przez wszystkie obliczenia zawinięty
>       w monadę M.

To działa tylko przy prostszych monadach, takich jak monada stanu.
Spróbuj to rozumowanie zastosować do monady IO z wątkami lub choćby do
monady parsowania ;)

>       'Na chłopski rozum': złożenie wielu obliczeń w jedno duże
>       obliczenie.

Dobrze jest myśleć o monadach od strony inżynierii oprogramowania, jako
o sposobie konstruowania interfejsu biblioteki.

Taki podstawowy interfejs sprawdził się w programowaniu funkcyjnym w
wielu zastosowaniach, pozwala praktycznie całkowicie ukryć
implementację, pozwala modelować różnego rodzaju efekty uboczne.

Można też myśleć o wyrażeniu/drzewie (może być nieskończone), które
opisuje obliczenia do wykonania, oraz program oglądający te drzewo,
wykonujący obliczenia i łączący wyniki obliczeń zgodnie z rodzajem
monady.

Znalazłem dobry opis tego, jak można myśleć o monadach w kontekście
tworzenia interpreterów:

   A good way to think of a monad is as an abstract datatype that
   captures the side effects and actions inherent in the language being
   translated in the methods of the abstract datatype. An important
   feature of a monad is that also describes, in a purely functional
   way, how these effects and actions interact.  Like any good abstract
   datatype, we are free to implement the actions in any way we want as
   long as our implementation behaves like its purely functional
   description.

Pozdrawiam,
Tomek

-- 
.signature: Too many levels of symbolic links