Funkcionální programátor

[JSH]

Jak to myslíš, že se to dá obejít? V rámci jedné aplikace se v jednom vlákně otevře soubor jako UT, a v jiném vlákně si ho otevřu taky? No tak to je mi ten UT dost k ničemu, když mám dvě reference na to samé. (Považuji to za dvě stejné reference, protože je to jen obálka nad tím souborem. Jak si systém zajistí, aby to tak bylo, už je implementační detail.)

Z pohledu typového systému jsou to dva objekty, co nemají nic společného (krom toho že to jsou soubory). Jakékoliv typování (nebo pravidla obecně) brání jen do určité míry. Kdo ho chce obejít, cestu si najde. Mimochodem třeba u souborů nemá program občas šanci poznat, že je to stejný soubor. Otevře dva a netuší jestli jeden není třeba symlink/hardlink/whatever. Tohle není jen záležitost funkcionálních jazyků. Podobné věci padají v diskuzích třeba o "#pragma once" v C.

[Reklama]

[BoneFlute]

Jak to myslíš, že se to dá obejít? V rámci jedné aplikace se v jednom vlákně otevře soubor jako UT, a v jiném vlákně si ho otevřu taky? No tak to je mi ten UT dost k ničemu, když mám dvě reference na to samé. (Považuji to za dvě stejné reference, protože je to jen obálka nad tím souborem. Jak si systém zajistí, aby to tak bylo, už je implementační detail.)

Z pohledu typového systému jsou to dva objekty, co nemají nic společného (krom toho že to jsou soubory). Jakékoliv typování (nebo pravidla obecně) brání jen do určité míry. Kdo ho chce obejít, cestu si najde. Mimochodem třeba u souborů nemá program občas šanci poznat, že je to stejný soubor. Otevře dva a netuší jestli jeden není třeba symlink/hardlink/whatever. Tohle není jen záležitost funkcionálních jazyků. Podobné věci padají v diskuzích třeba o "#pragma once" v C.

Bavíme se doufám o tom stejném, přístupu k souboru z jedné aplikace (ale třeba ve více vláknech), a zanedbání vnějšího vlivu?

V takovém případě k čemu to UT je, když nedělá ani takovou typickou věc?

[Inkvizitor]

Napsáno je to silně zjednodušeně, podstata je že k těm nepříjemným věcem jako RC dochází mimo vesmír celého funkcionálního cirkusu. Tudíž FP nemá možnost jak to ovlivnit nebo vyřešit.
Zjednodušeně buď budete hrát podle pravidel okolního světa a máte s FP problém, nebo si FP program spustíte v oddělené virtuální mašině kde si vytvoříte sluníčkový svět bez nebezpečných věcí a nemáte problém

Nevím, zda si všichni tak docela uvědomují, že vlastně všechny známé FP jazyky mají problém i s tím vlastním sluníčkovým světem. Jak jsme si tu dokázali v předchozích příspěvcích. To jen takovej malej rejp.

Nevím, na co přesně narážíš, ale mně přijde (konkrétně u Haskellu, který se tu probíral zleva i zprava), že ty problémy jsou vlastně všechny dány tím, že výpočet neprobíhá ve sluníčkovém světě.

[Greenhorn]

Dobrý den, skutečně mne zaujala tato diskuze, jsem totiž začátečník v Haskellu. Měl bych takovou malou otázku pro zdejší guru. Nezajímá mne teorie, pro programování používám selský rozum a intuici, takže odpověď ať je prosím alespoň trošku srozumitelná. Vždycky ve mne hlodali pochybnosti o čistotě IO v Haskellu. Jen si to vezměte, třeba knihovnu gtk2hs. Jedná se 1:1 namapování Cčkového API na Haskell API. A když poté takovou knihovnu používáme v Haskellu, používáme ji úplně stejně jako originální GTK v C. Kde je poté ta čistota a deklarativnost Haskellu? To už můžu rovnou psát v C, a budu to mít lehčí. Co mi vlastně ten Haskell přináší funkcionálního?

[JSH]

Bavíme se doufám o tom stejném, přístupu k souboru z jedné aplikace (ale třeba ve více vláknech), a zanedbání vnějšího vlivu?

V takovém případě k čemu to UT je, když nedělá ani takovou typickou věc?

Ty vnější vlivy se vlastně zanedbat ani nedají. Ale zkusím to vyjasnit

Když otevíráš soubor, tak zavoláš nějakou funkci která přes FFI zavolá něco co ten soubor otevře. Dostaneš zpět zabalený descriptor nebo handle. Ten zabalený descriptor ti už UT ohlídá tak, že se nedá jen tak zkopírovat a předat třeba různým vláknům.
Ale představ si, že máš funkci která dostane jeden unikátní soubor a vrací dva. Ta funkce je implementovaná zase přes FFI, protože uvnitř volá systém. Díky tomu překladač nemá šanci poznat, co se uvnitř děje. Může se tam zkopírovat deskriptor, nebo jen otevřít pomocný soubor atd. Stejně tak pro čtení, zápisy a i všechno ostatní musí funkce uvnitř ten descriptor vybalit a předat systému. A překladač může jen "doufat", že s tím vybaleným descriptorem děláš něco příčetného. Stejně tak ti typový systém neohlídá, že znova neotevřeš stejný soubor.

Takže ano, UT chrání před zkopírováním handle na soubor a předání do více vláken. Chrání ale jenom ocaď pocaď, protože se to dá poměrně jednoduše obejít. Ony i ty čisté funkce bez vedlejších efektů mívají občas vnitřnosti ve špinavém C. Jediná věc, která z nich dělá čisté je keyword, kterým programátor přísahá že nedělá žádné blbosti.

[Reklama]

[JSH]

Dobrý den, skutečně mne zaujala tato diskuze, jsem totiž začátečník v Haskellu. Měl bych takovou malou otázku pro zdejší guru. Nezajímá mne teorie, pro programování používám selský rozum a intuici, takže odpověď ať je prosím alespoň trošku srozumitelná. Vždycky ve mne hlodali pochybnosti o čistotě IO v Haskellu. Jen si to vezměte, třeba knihovnu gtk2hs. Jedná se 1:1 namapování Cčkového API na Haskell API. A když poté takovou knihovnu používáme v Haskellu, používáme ji úplně stejně jako originální GTK v C. Kde je poté ta čistota a deklarativnost Haskellu? To už můžu rovnou psát v C, a budu to mít lehčí. Co mi vlastně ten Haskell přináší funkcionálního?

Problém leží v tom, že všechny programy snad mimo konzolových filtrů mají za úkol dělat nějaké vedlejší efekty Teoreticky můžeme tvrdit, že v tom funkcionálním jazyce jen vytvoříme předpis, který se pak vykoná mimo. Prakticky ale IO monáda slouží k tomu, aby se kód s vedlejšími efekty udržel zavřený v kleci a nerozlezl se po celém programu. Drtivá většina kódu může být beze stopy IO monády.

A pak je třeba ST monáda a jí podobné. On je občas imperativní kód podstatně jednodušší než ten funkcionální. Takže můžeme napsat nějakou funkci imperativně, ale zvenku žádné vedlejší efekty mít nebude. Prostě to lepší z obou světů

[Greenhorn]

Dobrý den, skutečně mne zaujala tato diskuze, jsem totiž začátečník v Haskellu. Měl bych takovou malou otázku pro zdejší guru. Nezajímá mne teorie, pro programování používám selský rozum a intuici, takže odpověď ať je prosím alespoň trošku srozumitelná. Vždycky ve mne hlodali pochybnosti o čistotě IO v Haskellu. Jen si to vezměte, třeba knihovnu gtk2hs. Jedná se 1:1 namapování Cčkového API na Haskell API. A když poté takovou knihovnu používáme v Haskellu, používáme ji úplně stejně jako originální GTK v C. Kde je poté ta čistota a deklarativnost Haskellu? To už můžu rovnou psát v C, a budu to mít lehčí. Co mi vlastně ten Haskell přináší funkcionálního?

Problém leží v tom, že všechny programy snad mimo konzolových filtrů mají za úkol dělat nějaké vedlejší efekty Teoreticky můžeme tvrdit, že v tom funkcionálním jazyce jen vytvoříme předpis, který se pak vykoná mimo. Prakticky ale IO monáda slouží k tomu, aby se kód s vedlejšími efekty udržel zavřený v kleci a nerozlezl se po celém programu. Drtivá většina kódu může být beze stopy IO monády.

A pak je třeba ST monáda a jí podobné. On je občas imperativní kód podstatně jednodušší než ten funkcionální. Takže můžeme napsat nějakou funkci imperativně, ale zvenku žádné vedlejší efekty mít nebude. Prostě to lepší z obou světů

Děkuji za odpověď. Takže pokud to správně chápu, IO monáda je impure.

[Mirek Prýmek]

Děkuji za odpověď. Takže pokud to správně chápu, IO monáda je impure.

Monády jsou určené k tomu, abys mohl řídit pořadí, ve kterém se něco provede. Jestli tomu chceš říkat "impure", je už na tobě

[lkm]

To už můžu rovnou psát v C, a budu to mít lehčí. Co mi vlastně ten Haskell přináší funkcionálního?

Budete. Přináší možnost napsat si zásadní výpočetní algoritmy funkcionálně, praktické využití celého FP je úměrné výskytu těchto vhodných algoritmů. Na Libre Office je to asi k ničemu, na výpočet dráhy letu na Mars je to vhodné velmi.

[v]

byla by věčná škoda nechat tohle vlákno zapadnout, vždyť jsme se ještě ani nedobrali k tomu funkcionálnímu oscilátoru

je obecná monáda "pure"? proč IO není?

[Mirek Prýmek]

je obecná monáda "pure"?

Musel bys ten pojem presne definovat... "Uvnitr" jazyka asi ano, z pohledu zvnejsku ne - protoze nejak meni svet, coz, jak uz tady zaznelo, matematicka funkce nikdy nemuze...

proč IO není?

Protoze vykonava nejakou cinnost.

[BoneFlute]

Napsáno je to silně zjednodušeně, podstata je že k těm nepříjemným věcem jako RC dochází mimo vesmír celého funkcionálního cirkusu. Tudíž FP nemá možnost jak to ovlivnit nebo vyřešit.
Zjednodušeně buď budete hrát podle pravidel okolního světa a máte s FP problém, nebo si FP program spustíte v oddělené virtuální mašině kde si vytvoříte sluníčkový svět bez nebezpečných věcí a nemáte problém

Nevím, zda si všichni tak docela uvědomují, že vlastně všechny známé FP jazyky mají problém i s tím vlastním sluníčkovým světem. Jak jsme si tu dokázali v předchozích příspěvcích. To jen takovej malej rejp.

Nevím, na co přesně narážíš, ale mně přijde (konkrétně u Haskellu, který se tu probíral zleva i zprava), že ty problémy jsou vlastně všechny dány tím, že výpočet neprobíhá ve sluníčkovém světě.

No asi takhle. Když se řekne, že použitím unsafePerformIO a spol opouštím sluníčkoví svět FP, tak fajn. Jenže už se neřeklo, že opuštění sluníčkového světa stačí použít IOMonády. To překvapí. Vyvolává to totiž dojem, že právě proto je to do té monády zabalené, aby se to vytklo, a výpočet se prováděl mimo sluníčkový svět, a ten vnitřní sluníčkový tím nebyl poznamenán. Což se ale neděje. (Ve skutečnosti je to do monády zabalené jen kůli pořadí vykonání. A o riziku soubězích ve více vláknech se nemluví.)

[BoneFlute]

proč IO není?

Protoze vykonava nejakou cinnost.

Protože nic nezaručuje? (Pure funkce je schopná zaručit, že nebudou porušeny principy FP, zatímco IOMonáda toto zaručit nemůže.)

[JSH]

Protože nic nezaručuje? (Pure funkce je schopná zaručit, že nebudou porušeny principy FP, zatímco IOMonáda toto zaručit nemůže.)

Ale IO monáda nepořušuje žádné principy FP. IO monáda je jen obal funkcí co berou jako parametr celý svět a vracejí ho upravený. Ty funkce, co upravují svět, nemají žádné vedlejší efekty. Ta úprava světa proběhne přesně ve stylu matematicky definovaných funkcí.

Pořád tady mluvíš o porušování nějakých pricipů FP. Žádné principy porušené nejsou. Který princip je podle tebe porušený? Jediný rozdíl mezi IO a zbytkem světa je v tom, že v IO jsi součástí návratové hodnoty

[BoneFlute]

Protože nic nezaručuje? (Pure funkce je schopná zaručit, že nebudou porušeny principy FP, zatímco IOMonáda toto zaručit nemůže.)

Ale IO monáda nepořušuje žádné principy FP. IO monáda je jen obal funkcí co berou jako parametr celý svět a vracejí ho upravený. Ty funkce, co upravují svět, nemají žádné vedlejší efekty. Ta úprava světa proběhne přesně ve stylu matematicky definovaných funkcí.

Pořád tady mluvíš o porušování nějakých pricipů FP. Žádné principy porušené nejsou. Který princip je podle tebe porušený? Jediný rozdíl mezi IO a zbytkem světa je v tom, že v IO jsi součástí návratové hodnoty

Vím jak monáda funguje. To netřeba opakovat.

IO Monáda umožní souběh. To ti nepřijde jako porušení referenční transparentnosti?