Má Haskell budoucnost?

[Kit]

Prostě IO v Haskellu je totéž, jako by to byl string "načti_ze_stdio", "zapiš_do_souboru", ... a tyhle statické, symbolické popisy IO akcí by se řadily za sebe třeba do Listu. Monády jsou to samé, akorát mi umožňují předávat mezi IO akcemi libovolná data a checkovat jejich typy. Nic víc, jenom prostě řazení IO operací. Plus možnost failnout. A bindIO dělá to samé, akorát ne obecně pro jakoukoli monádu, ale jenom specificky pro IO akce. Takže (>>=) není nic jiného než zobecnění bindIO na jakoukoli monádu. (EDIT: z čehož právě plyne, že když specifikace obsahuje Monad, tak nepotřebuje explicitní bindIO, může ho schovat v implementaci, což je přesně to, co jsem řekl a nevidím tam nic nepravdivého)

Dají se tedy monády přirovnat např. k pojmenovaným rourám s definovanou vnitřní strukturou?

[Reklama]

[Radek Miček]

Živím se jako programátor, naučím se Haskell... bude mi to v práci k něčemu?

Otázkou je, k čemu přesně by to mělo být. Řada věcí, co Haskell nabízí, je v jiných jazycích řešena lépe a jednodušeji než v (GHC) Haskellu.

Například, pokud si chcete pohrát se silnějším typovým systémem, můžete zkusit Idris (BTW Idris má lepší mechanismus pro sledování efektů než Haskell). Pokud chcete další možnosti, jak řídit běh programu, můžete zkusit jazyk s podporou delimited continuations (např. vhodný dialekt Scheme nebo v omezené formě ocaml-multicore nebo OCaml s knihovnou delimcc), pokud chcete paralelismus, zkuste Clojure nebo Manticore.

V současné době jsem dostal firemní PC s windows, tak se chci naučit .NET...

Pokud se chcete učit .NET, tak možná bude mít smysl kouknout se na F#, až se naučíte C#.

[Mirek Prýmek]

Dají se tedy monády přirovnat např. k pojmenovaným rourám s definovanou vnitřní strukturou?

Přesně tak - to jsou právě ty koleje, o kterých jsem mluvil nedávno. A hezký je na tom to, že je zabezpečeno, že spojit jdou jenom koleje, který na sebe pasují (předchozí fce vrací IO akci stejného typu jako následující lambda bere jako vstup).

[andy]

To zjevně není pravda:

Be warned that modifySTRef does not apply the function strictly. This means if the program calls modifySTRef many times, but seldomly uses the value, thunks will pile up in memory resulting in a space leak. This is a common mistake made when using an STRef as a counter. For example, the following will leak memory and likely produce a stack overflow:

https://hackage.haskell.org/package/base-4.8.2.0/docs/Data-STRef.html#v:modifySTRef

Tenhle problém není u writeSTRef, protože ten předchozí stav (řetězec thunků) zahodí, takže nic nebobtná.

Z toho mi přijde, že to je zjevně řetězec lambd (thunků). EDIT: jakože řetězec modifikací stavu.

Já ti teď vůbec nerozumím. Řetězení lambd v monadu chápu jako řetězení ST () akcí. To se neděje. Vykonává se to stejně jako IO monad, dokonce vevnitř to je snad nějaký hodně podobný (akorát místo RealWorld tam je něco jiného). Co se může stát je, že STRef může obsahovat thunk (asi... nikdy jsem s tím nedělal), takže pokud to neforcneš, tak si v tom můžeš ten lazy pure výpočet nařetězit. Ale to nemá s ST nic společného. Ten 'zápis (toho thunku) do ST' se nikde neřetězí, ten se provede.

[andy]

Dají se tedy monády přirovnat např. k pojmenovaným rourám s definovanou vnitřní strukturou?

Tak ten vtip zní "A monad is just a monoid in the category of endofunctors". Tak prozatím to chápu tak, že "monoid" znamená v podstatě "list" nebo "stream" a "kategorie endofunktorů" znamená, že jsem z té akce v listu schopen vytáhnout hodnotu a nějak ji předat následujícím akcím..

[Reklama]

[Mirek Prýmek]

Tak ten vtip zní "A monad is just a monoid in the category of endofunctors". Tak prozatím to chápu tak, že "monoid" znamená v podstatě "list" nebo "stream" a "kategorie endofunktorů" znamená, že jsem z té akce v listu schopen vytáhnout hodnotu a nějak ji předat následujícím akcím..

Tak to chápeš blbě Monoid znamená, že pro tu věc platí pravidla monoidu (asociativita a existence neutrálního prvku) a endofunktor je funktor, který mapuje kategorii na sebe samu.

Endofunktor je to proto, že libovolný haskellovský typ mapuje opět na haskellovský typ. A monoid je to proto, že bind je asociativní a return je neutrální prvek.

...ale neřekl bych, že by komukoli "normálnímu" tahle definice pomohla pochopit, o co jde

[Mirek Prýmek]

Já ti teď vůbec nerozumím. Řetězení lambd v monadu chápu jako řetězení ST () akcí. To se neděje. Vykonává se to stejně jako IO monad, dokonce vevnitř to je snad nějaký hodně podobný (akorát místo RealWorld tam je něco jiného). Co se může stát je, že STRef může obsahovat thunk (asi... nikdy jsem s tím nedělal), takže pokud to neforcneš, tak si v tom můžeš ten lazy pure výpočet nařetězit. Ale to nemá s ST nic společného. Ten 'zápis (toho thunku) do ST' se nikde neřetězí, ten se provede.

A proč teda podle tebe v tom příkladu dojde ke stack overflow?

[gl]

Řetězení ST akcí znamená, že se provádí sekvenčně uvnitř runST bloku. Tak jsem pochopil Andyho odpověď já. Na žádný zásobník se nic neukládá. Když STRef přepíšete, tak se předchozí hodnota ztratí. Funguje to stejně jako proměnná v C.

To zjevně není pravda:

Be warned that modifySTRef does not apply the function strictly. This means if the program calls modifySTRef many times, but seldomly uses the value, thunks will pile up in memory resulting in a space leak. This is a common mistake made when using an STRef as a counter. For example, the following will leak memory and likely produce a stack overflow:

https://hackage.haskell.org/package/base-4.8.2.0/docs/Data-STRef.html#v:modifySTRef

Tenhle problém není u writeSTRef, protože ten předchozí stav (řetězec thunků) zahodí, takže nic nebobtná.

Z toho mi přijde, že to je zjevně řetězec lambd (thunků). EDIT: jakože řetězec modifikací stavu.

Máte pravdu. To jsem přehlédl. Předtím se mluvilo o writeSTRef. Jde tam jen o líné vyhodnocení argumentu. V dokumentaci se doporučuje použít modifySTRef'.

[andy]

a jinak, k otázce budoucnosti... další pohled: Živím se jako programátor, naučím se Haskell... bude mi to v práci k něčemu? V současné době jsem dostal firemní PC s windows, tak se chci naučit .NET... protože ta znalost mě může jednoho dne živit... ale Haskell? Krom takového toho domácího žvýkání...

No já jsem pochopil, co to znamená typový systém. Ano, některé jiné jazyky mají ještě lepší, ale ten v haskellu je úplně někdy jinde než cokoliv "normálních" a navíc na to je kvantum knihoven a dá se v tom suprově programovat.

Jinak když se podívám na svoje projektíky, tak chvíli to trvalo, ale v současné době už mám za sebou (a v procesu) pár projektů, na které jsem použil zčásti nebo úplně haskell. Jako v Java shopu asi není šance prorazit s čímkoliv jinám než Javou, na druhou stranu.... třeba dělal jsem webový "dotazník". Myslel jsem si, že to nějak splichtím v čemkoliv, jenže ve výsledku to bylo cca. 400 otázek s různými typy závislostí (když tohle je Ano, tohle nevyplňovat a tohle nastavit natvrdo na Ne apod.). Takže představa, že to budu dělat "normálně" vzala za své.

Takže jsem si napsal parser nějakých jednoduchých výrazů (většinou bool), nějaký jednoduchý popis toho dotazníku v Yamlu, frontend jsem měl v angularu, takže generátor javascriptu, který dělal online validaci a reakce všech těch položek na kliknutí (disable atp.), a generátor SQL create table se všemi nadefinovanými constrainty (to SQL má asi 450 řádek na 1 tabulku). Navíc ještě kontroloval, jestli jsou ty výrazy správně a nejsou tam překlepy v proměnných apod. Výsledek - po odladění to fungovalo naprosto bez chyby. Za ten rok, co to běželo, jsem nedostal jediný bug report - a to to v podstatě nikdo pořádně před nasazením netestoval.

A tohle je něco, s čím se při "normálním" programování můžeš setkat a v Haskellu se to řeší v zásadě dost triviálně. Připadá mi, že haskell má hodně dobrou podporu webových služeb, slušnou zásobu knihovan na normální práci. Takže řekl bych, že praktické využití je fakt velké, jen se člověk musí odhodlat. Ale pak zjistíš, že to odhodlání stojí za to:)

[Mirek Prýmek]

Takže jsem si napsal parser nějakých jednoduchých výrazů (většinou bool), nějaký jednoduchý popis toho dotazníku v Yamlu, frontend jsem měl v angularu, takže generátor javascriptu, který dělal online validaci a reakce všech těch položek na kliknutí (disable atp.), a generátor SQL create table se všemi nadefinovanými constrainty (to SQL má asi 450 řádek na 1 tabulku). Navíc ještě kontroloval, jestli jsou ty výrazy správně a nejsou tam překlepy v proměnných apod. Výsledek - po odladění to fungovalo naprosto bez chyby. Za ten rok, co to běželo, jsem nedostal jediný bug report - a to to v podstatě nikdo pořádně před nasazením netestoval.

A kdybys to rovnou napsal v Elmu, tak seš na tom stejně a ještě ti odpadne to generování javascriptu

[andy]

Já ti teď vůbec nerozumím. Řetězení lambd v monadu chápu jako řetězení ST () akcí. To se neděje. Vykonává se to stejně jako IO monad, dokonce vevnitř to je snad nějaký hodně podobný (akorát místo RealWorld tam je něco jiného). Co se může stát je, že STRef může obsahovat thunk (asi... nikdy jsem s tím nedělal), takže pokud to neforcneš, tak si v tom můžeš ten lazy pure výpočet nařetězit. Ale to nemá s ST nic společného. Ten 'zápis (toho thunku) do ST' se nikde neřetězí, ten se provede.

A proč teda podle tebe v tom příkladu dojde ke stack overflow?

No, vyhodnocuje se následující:
Obsah STRef: 0
po 1 kroku replicate:
Obsah STRef: (+ 1) 0
po 2 kroku replicate
Obsah STRef: (+ 1) . (+ 1) $ 0
atd.

Ty "kroky" se neřetězí. To je úplně stejný problém jako foldl (+) 0 [1..1000000]. Je to problém laziness v pure výpočtech, nikoliv řetězení v ST monadu.

[andy]

Takže jsem si napsal parser nějakých jednoduchých výrazů (většinou bool), nějaký jednoduchý popis toho dotazníku v Yamlu, frontend jsem měl v angularu, takže generátor javascriptu, který dělal online validaci a reakce všech těch položek na kliknutí (disable atp.), a generátor SQL create table se všemi nadefinovanými constrainty (to SQL má asi 450 řádek na 1 tabulku). Navíc ještě kontroloval, jestli jsou ty výrazy správně a nejsou tam překlepy v proměnných apod. Výsledek - po odladění to fungovalo naprosto bez chyby. Za ten rok, co to běželo, jsem nedostal jediný bug report - a to to v podstatě nikdo pořádně před nasazením netestoval.

A kdybys to rovnou napsal v Elmu, tak seš na tom stejně a ještě ti odpadne to generování javascriptu

Potřeboval jsem to napsat cca. před rokem a půl, angular jsem uměl, o Elmu jsem nevěděl a měl jsem na to míň než měsíc Dneska bych možná šáhnul po Elmu nebo Purescriptu, kdyby byl čas se to naučit (teď se učím purescript...)

[Mirek Prýmek]

No, vyhodnocuje se následující:
Obsah STRef: 0
po 1 kroku replicate:
Obsah STRef: (+ 1) 0
po 2 kroku replicate
Obsah STRef: (+ 1) . (+ 1) $ 0
atd.

Ty "kroky" se neřetězí. To je úplně stejný problém jako foldl (+) 0 [1..1000000]. Je to problém laziness v pure výpočtech, nikoliv řetězení v ST monadu.

Tak to jsme si asi v něčem nerozuměli, protože výrazu "(+ 1) . (+ 1) $ 0" já říkám zřetězení

Prostě bavili jsme se o tom, že v rámci STM se neděje* žádná tajemná nečistá inplace magie.

* alespoň formálně - v implementaci můžou být kdovíjaké figly

[andy]

Tak to jsme si asi v něčem nerozuměli, protože výrazu "(+ 1) . (+ 1) $ 0" já říkám zřetězení

Prostě bavili jsme se o tom, že v rámci STM se neděje* žádná tajemná nečistá inplace magie.

* alespoň formálně - v implementaci můžou být kdovíjaké figly

Ale to není monadické řetězení. Neřetězí se ti ST akce, řetězí se ti aplikace funkce, ale ta nemá s ST vůbec nic společného. Řetězením v monadu rozumím například to, že když asociuješ tu >>= operaci opačně, tak to pak má třeba kvadratickou složitost apod. Což se myslím projevuje nějak u Pipe, kdy se to za určitých okolností takhle blbě může chovat. Ale tohle je trošku nad moje schopnosti (prý se to řeší nějakým "CoYoneda monadem" nebo co...)

[andy]

Prostě bavili jsme se o tom, že v rámci STM se neděje* žádná tajemná nečistá inplace magie.

No ten STRef je v implementaci fakt normální mutable proměnná, akorát že ukazuje na thunk, čili může obsahovat výpočet. Jestli je schopne to při dostatečné striktnosti kompiler nějak vyoptimalizovat pryč, to netuším.