Příspěvky

1891

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 06. 07. 2015, 21:41:27 »

Protože přece o přesně o tomhle to bylo. Ty sám jsi tuším řekl, že napsat to čistě bez vláken je triviální.

Nebylo. Bylo to o tom, že Clean to má údajně uděláno dobře. Akorátže jenom pro jedno vlákno. Což je podmínka, za které jsou monády úplně stejně dobré.

Clean neznám. Ale pokud je schopen používat IO bez souběhu, tak to řeší dobře. A že to implementuje tím, že zakáže vlákna? Hm, no a?

Pokud ti monády zajišťují pořadí výpočtu, ale jen někdy, tak je to zajištění dost hloupé, to se na mě nezlob.

No zajišťují ti pořadí výpočtu v jednom vlákně - vytvářejí ti prostě možnost kousek kódu psát "imperativně" (do block). Pokud chceš nějakou synchronizaci mezi vlákny, je na to potřeba jiný nástroj. Na tom mi nepřijde nic polovičatého. Monády prostě dělají to, co dělat mají.

Jak to chápu a jak jsem tomu porozuměl, jsou dva rozměry:
a/ Monády, které definují pořadí vyhodnocení výrazů, které jsou uvnitř. Unique typing, které definuje, že nějaký výraz bude jen jednou (zde trochu plavu, přiznávám, doufám, že to mám dobře).
b/ Haskell, který na IO používá systém monád, který ale nefunguje korektně ve více vláknech, protože Monádám je to jedno, o vlákna ani o unikátnost se nestarají.
Clean (a nebo další jazyky), které na IO používají  Unique typing (nebo react, nebo cokoliv), což řeší problém ve více vláknech, protože Unique typingu to jedno není, a tak se to řeší během v jednom vláknu.

Monády se nestarají o unikátnost, tudíž jim vlákna nevadí, a proto vzniká problém až v dalším kole. Zatím Unique typing (jak jsem to pochopil) řeší unikátnost, tak se s vlákny musí vývojář interpretu - ne jazyka, poprat.

Ano, pokud bych spouštěl aplikaci v jednom vláknu, tak jsou na to Monády stejně dobré jako UT. Jenže z ideového hlediska mi nic nebrání, abych Monády pouštěl ve více vláknech. Sice to nebude fungovat, ale můžu. Zatímco u Unique typingu to ideově vadí.

1892

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 06. 07. 2015, 21:09:24 »

Imho to máš moc dlouhý. IOMonády nejsou čisté, protože umožňují RC. Přesněji, protože je nejde použít tak, aby k němu nemohlo dojít.
Nejde o to, že Haskell má forkování IO, ale o to, že nemá možnost, jak zabránit v IO race condition (při vícevláknovém běhu).

No, možná bych to popsal takto: unsafeIO mi jasně říká, že se bude dít nějaká divočina. Použitím více vláken mi nijak nenaznačuje - bacha, IOMonády nebudou fungovat korektně.

To je pořád totéž: monády umožňují RC jenom při běhu ve více vláknech. Údajné řešení běh více vláken neumožňuje. Není tedy o nic lepší než monády.

Což ale u více vláken neplatí. Nebo se pletu?

Proč by to neplatilo? Monády jsou prostě způsob, jak lazy jazyk donutit dodržet nějaké pořadí vyhodnocování.

Ve více vláknech máš pak samozřejmě problém jejich prolínání, takže by se případně hodil i nějaký další mechanismus pro řazení těch vláken mezi sebou. To ale ten čumilem vyzdvihovaný Clean taky nedělá.

Protože přece o přesně o tomhle to bylo. Ty sám jsi tuším řekl, že napsat to čistě bez vláken je triviální.

To není pořád totéž, to je to na tom zásadní. Pokud ti monády zajišťují pořadí výpočtu, ale jen někdy, tak je to zajištění dost hloupé, to se na mě nezlob.

Proto jsem psal, že monády jsou nevhodně zvolený nástroj. Protože z toho jakože matematického hlediska dělají co mají a dělají to správně. Ale z praktického hlediska to nefunguje.

1893

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 06. 07. 2015, 20:54:31 »

Já ho teda pochopil jinak. Jemu IMHO nešlo o to, že tam je nějaké forknutí  IO, nebo, že to jde obejít,

Začátek je tady: http://forum.root.cz/index.php?topic=11417.msg134386#msg134386 IO monáda není čistá, protože čisté IO neumožňuje race condition. A IO kdekoli (nejen v Haskellu) umožňuje RC jenom při vícevláknovém běhu. Čili IO v Haskellu není čisté právě proto, že umožňuje fork. Mně to přijde jako jednoduchý sylogismus

Imho to máš moc dlouhý. IOMonády nejsou čisté, protože umožňují RC. Přesněji, protože je nejde použít tak, aby k němu nemohlo dojít.
Nejde o to, že Haskell má forkování IO, ale o to, že nemá možnost, jak zabránit v IO race condition (při vícevláknovém běhu).

No, možná bych to popsal takto: unsafeIO mi jasně říká, že se bude dít nějaká divočina. Použitím více vláken mi nijak nenaznačuje - bacha, IOMonády nebudou fungovat korektně.

ale o to, že monády z principu neřeší problém. Jedná se o nevhodné použití nástroje na problém vstupu a výstupu. Vždyť na IO se monáda používá jen proto, že umožňuje určit pořadí vyhodnocování. To je dost polovičaté, nemyslíš?

Vůbec ne, protože řazení funkcí ve správném pořadí je to jediné, co u lazy jazyka pro IO potřebuješ. Nebýt línosti, monády bys vůbec nepotřeboval, protože referenční transparentnost máš zadarmo zaručenou tím, že funkci voláš pokaždé s jiným stavem světa, čili defacto volání funkce můžeš výslednou hodnotou nahradit jenom na tom jednom konkrétním místě.

Což ale u více vláken neplatí. Nebo se pletu?

1894

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 06. 07. 2015, 20:27:18 »

Napřed se objevil čumil, a začal vcelku logicky uvádět věci na pravou míru. [...] Závěr je ten, že čumil říkal že Haskell není čistý [...] ostatní zde tvrdili že Haskell je čistý

To jsi to špatně pochopil. Haskell umožňuje operaci, která může potenciálně způsobovat problémy (forknutí IO). Čumil řekl, že to je blbý a že lepší je řešení s UT. Jenže prakticky úplně stejného řešení dosáhneš s Haskellem pokud forknutí IO nepoužiješ. A naopak - pokud bys do jakéhokoli jazyka možnost mít víc IO vláken přidal, dostaneš se přesně tam, kde je Haskell. Proto je ta čumilova výhrada vůči Haskellu divná. Nikdo z něj nedělal blbce, ale těžko jazyku vyčítat, že má cosi navíc, co případně může způsobit problémy, a dávat za příklad jazyk, který tohle cosi navíc nemá a proto nemá ani ty problémy.

Já ho teda pochopil jinak. Jemu IMHO nešlo o to, že tam je nějaké forknutí  IO, nebo, že to jde obejít, ale o to, že monády z principu neřeší problém. Jedná se o nevhodné použití nástroje na problém vstupu a výstupu. Vždyť na IO se monáda používá jen proto, že umožňuje určit pořadí vyhodnocování. To je dost polovičaté, nemyslíš?

1895

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 13:37:59 »

ještě jednou mimo hlavní tok diskuze - napsali jste už nějakou netriviální aplikaci ve funkcionálním jazyce? co a v jakém?
já kalkulačku (jak jinak) a tvořím překladač jednoho ne moc známého programovacího jazyka, v Haskellu

Dělal jsem hru, byl na výběr z několika perokreseb, menu s barvičkama, a uživatel tam myší vyplňoval barevné plochy. Načítání z png, svg.

1896

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 13:35:13 »

Pro účely téhle debaty je podle mě nutný jazyk (syntaxe + typový systém) a runtime (sémantika, "výkonný stroj") odlišovat jako dvě různé věci.

Pořád nám zůstává otázka, jestli by nešel typový systém udělat tak, aby umožňoval běh ve víc vláknech a zároveň by nějakou typovou magií uměl poskytovat nějaké záruky ohledně těch vláken. Radek zmiňoval Rust a Mezzo. Já je neznám, takže neumím posoudit, jestli to takhle nějak dělají.

Odporuješ si. Pokud typem zajistíš, že nedojde k souběhu, a runtime to pak nedodrží tak jsi zase na začátku. Ono stačí prohlásit, že předpis je funkcionální, a už nesmí dojít k souběhu.

Ještě jeden příklad:
Budeme mět tu funkci sum :: Int -> Int -> Int. Tato funkce je implementována přímo v nějaké Cčkovské rutině, takže naprosto mimo kontrolu engine atd. Ale přestože je tato funkce blackbox, tak si nemůže dovolit (a věřím, že je to i nějak ošéfovaný) vracet string. To prostě nemůže. Nebo může?

Krom toho ta funkce může dělat i milion dalších věcí nad rámec typu. Může vypisovat do konzole, přepisovat disk a podobně. Haskell může jenom věřit programátorovi, že tam nedělá žádné prasárny. Pokud jo, smůla.

Co je nad rámec typu, to mě nezajímá. Ale musí vrátit Int. A musí jít substituovat za její hodnotu. A pokud té funkci takové substituování vadí, tak porušuje kontrakt, není funkcionální.

1897

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 03:20:45 »

Když ti typový systém umožní zajistit, aby návratová hodnota byla číslo, proč by nemohla hlídat čistotu bazénu? V čem je principielní rozdíl?

Myslím jako opravdu fyzicky vyčistit, asi nepodařenej vtip

Je to nadsázka, ale ano opravdu fyzicky vyčistit: fill :: CleanPool -> IO Pool.

Důvod takového dogmatu?

To není dogma. Ale neumím si představit, jak bys chtěl purity definovat tak, aby se vztahovala na runtime. Ty totiž mj. jako programátor vůbec netušíš, co runtime dělá. Možná sdružuje nějaké struktury, možná si něco cachuje, možná něco mění in-situ, protože si spočítal, že to v tenhle okamžik udělat může. Nevíš. Runtime by měl jenom dodržet sémantiku jazyka, nic víc nevíš.

Čili "pure runtime" mi přijde podobné jako "modrá myšlenka". Podle mě bys musel nadefinovat nějak zvláštně slovo "modrá", aby to dávalo nějaký smysl.

Omlouvám se, myslím, že už chápu. Ano, spíše bych to měl nazvat korektností, než čistotou. A ve smyslu právě korektnosti = jakože ten engine korektně spracuje předpis, jsem to myslel. Mám za to, že smysl mých příspěvků by to nemělo změnit. A za nevhodně zvolený výraz se omlouvám.

1898

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 02:50:40 »

Ty se domníváš, že jazyk nemůže zakázat souběh tak nějak z principu? Nebo jak to myslíš?

Řekl bych to úplně jednoduše takhle: role jazyka jako takového končí tím, jestli program jde nebo nejde přeložit. Čili jestli je syntakticky a typově správný. Nic víc po jazyku jako takovém nemůžeš chtít. Nemůže nic tušit o nějakém souběhu, nemůže ti zaručit správnost výpočtu, nemůže ti uvařit kafe ani vyčistit bazén. Čili na otázku "Ty se domníváš, že jazyk nemůže vyčistit bazén tak nějak z principu?" bych asi odpověděl "ano, tak nějak z principu"

Ale zároveň si myslím, že to je jenom terminologické nedorozumění, že totiž pod pojem "jazyk" zahrnuješ třeba i interpret, standardní knihovnu atd. Já pod tím pojmem teď myslím fakt jenom "pravidla správné syntaxe" + typový systém.

Když ti typový systém umožní zajistit, aby návratová hodnota byla číslo, proč by nemohla hlídat čistotu bazénu? V čem je principielní rozdíl?

a tudíž je IMHO pure

Ještě jednou: purity je podle mýho vlastnost jazyka a nedává žádný smysl ji vztahovat na runtime.

Důvod takového dogmatu?

1899

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 02:45:35 »

Hele, nemůžeme si tykat?

Můžem. To vám, bylo tobě a Radkovi Míčkovi, a ostatním.

Představím si, že jsem kompilátor (naivní), tak bych z toho udělal switch, kde na základě toho první bajtu v souboru se rozhodnu jak budu pokračovat v dalších 256 cestách. Takhle si to představuji já, a takhle o tom uvažuji. Ale asi to stále není to, co máte na mysli.

Jediný, co jsem měl namysli, je ten rozdíl mezi programem, který žije v ideálním světě, kde nic není potřeba načítat a všechno je jenom statická relace, a skutečným světem, kde je potřeba dělat nějakou činnost. V tom ideálním světě tě nijak netrápí souběhy a ani o nich vůbec nemá smysl hovořit*, protože vše je statické, nic se nemusí vypočítat, nic se nespouští.

No, ale dyť jo. Jenže rozdíl je mezi mou naivní implementací 256pozičního switche, která vždycky vybere nějakou cestu, a tudíž je IMHO pure; a mezi jinou implementací, která se na něco ptá bůhví čeho, a při tom dotazu se zasekne a čeká, a čeká, a čeká... a to (opět IMHO) nesmí. Protože pak vzniká ten rozpor mezi ideálním světem, a tím skutečným.

Dobrou.

1900

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 02:36:36 »

Pokud ti jazyk zakazuje souběh, tak ho runtime nemůže udělat. Pokud jazyk nespecifikuje takovou situaci, pak ano.

Jazyk právě souběh nijak zakázat nemůže, to jde úplně mimo něj.

Já se právě domnívám, že čumil přišel s tezí, že IOMonády se o toto snaží, a neúspěšně, a že jsou jiné a lepší a hlavně funkční způsoby, kterými by to jít mělo.
Zda má pravdu či ne, to už je jiná.

Ty se domníváš, že jazyk nemůže zakázat souběh tak nějak z principu? Nebo jak to myslíš?

Nerozumím tomu, jak by mohl mět jeden jazyk více sémantik (významů výrazů)? Můžeš to rozvést?

Polopaticky řečeno, jazyk přece neřeší, co ty funkce opravdu dělají. Pro něj jsou to totální blackboxy. Zná jenom typ vstupů a typ výstupu, ale co se uvnitř opravdu děje, neřeší.

Příklad pro ten souběh: "ví" jazyk C, že fork spouští nějaký nový proces? Vůbec. Jak by ti jazyk jako takový mohl zakázat spustit nový proces, když on vůbec netuší a neřeší, co fork dělá. Pro něj je to prostě jenom "pid_t fork(void)" a pokud mu nedáváš žádný parametr a nechceš z něj dostat string, je happy

Pokud bys chtěl fork neumožnit, tak to uděláš třeba tak, že tvůj runtime vůbec nebude fci fork mít a nebude umožňovat volat systémová volání. A pak neforkneš ani kdyby ses na hlavu postavil. Ale jazyk za to nemůže, může za to runtime

Ano, funkce jako blackbox vnímám stejně. Zná jen typ vstupů a výstupů.

A teď k tomu souběhu:
Java-like jazyky souběh řeší výjimkou. Tu si odchytíš, a něco provedeš.
Pure funkcionální jazyky souběh neumožňují, protože to odporuje jejich filozofii.

Takže, když jsem to popsal takto, tak ano, funkce jsou totální černé skříňky, ale to neznamená, že si ta černá skříňka může dělat úplně co chce. Nemůže. V typovaných jazycích se musí zodpovídat deklarovanému typu, a v pure funkcionálních jazycích si nesmí dovolit (mimojiné) souběh. (V jazycích s GC překvapí, když dojde k memory-leaku, zatímco u takového C se to považuje za povinnost programátora.)

Ještě jeden příklad:
Budeme mět tu funkci sum :: Int -> Int -> Int. Tato funkce je implementována přímo v nějaké Cčkovské rutině, takže naprosto mimo kontrolu engine atd. Ale přestože je tato funkce blackbox, tak si nemůže dovolit (a věřím, že je to i nějak ošéfovaný) vracet string. To prostě nemůže. Nebo může?

1901

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 02:17:12 »

3. A teď, když budu mět funkci openFile :: FilePath -> IOMode -> IO Handle, tak na první pohled se chová jako můj druhý příklad. Jenže ve skutečnosti já nikdy nevím, kterou z těch dvou možností (otevře soubor | zařve) udělá. A to mě přijde jako dost velký rozdíl.

Nevím, jestli ti úplně rozumím. Zkusme si vzít raději operaci "načtení prvního bajtu ze souboru" a opět ji zapsat jako relaci... Jako máš [{1,2},{2,3},...] tak teď budeš mít jakoby navíc parametr "stav světa", který můžeš efektivně zúžit na "stav toho souboru, který mě zajímá", a dostaneš něco jako

Kód: [Vybrat]

[{"aaaa","a"},{"abbb","a"},{"baaa","b"},...]

kde ten jeden parametr je "faktický obsah souboru" a to druhý je výsledek fce "načti mi první byte".  Tohle je naprosto čistá fce. Žádná magie, žádný monády, nic. Zcela čistá matematická fce. Čili jazyk jako takový nemá problém.

Jenže když ten program budeš chtít spustit (pomocí nějakého toho "stroje", jak jsem to psal výš), tak ten stroj musí ten skutečný stav světa zjistit - provést nějakou činnost. Tu činnost nedělá jazyk, tu dělá runtime. Jazyk zná jenom tu relaci, což je čistě statická, naprosto pure záležitost kde o žádném "spuštění" nedává vůbec smysl hovořit.

(Jé, já se tak těším na ten aha efekt.)

Představím si, že jsem kompilátor (naivní), tak bych z toho udělal switch, kde na základě toho první bajtu v souboru se rozhodnu jak budu pokračovat v dalších 256 cestách. Takhle si to představuji já, a takhle o tom uvažuji. Ale asi to stále není to, co máte na mysli.

Když si to pročítám, pro mě není problém, že si stroj musí zjistit skutečný stav světa, nebo, že musí provést nějakou činnost. To ať si dělá. Pro mě je kruciálně zásadní, že když předpis říká: tenhle vzorec skončí číslem, tak engine vrátí číslo. (Jestli ho nejdříve zjistí, nebo ne, mě nezajímá.) Když předpis říká, tenhle vzorec skončí výpisem obsahu souboru na obrazovku, tak engine vypíše obsah souboru na obrazovku. A že ten soubor nemá? To má blbý, jeho chyba. Předpis s tím nepočítal? Jak je to možné? To bude nějaká chyba jazyka.

Atd.

1902

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 02:02:12 »

Takže si asi dokážeš představit, že mě moc netankuje když sice jazyk je pure, ale že kompilátor si dělá něco jiného je v pořádku.

Podle mě si úplně nerozumíme. Kompilátor/runtime si nedělá něco jiného. Dělá přesně to, co mu sémantika jazyka ukládá udělat. To ale nic nemění na tom, že pro jeden jazyk bys mohl mít sémantiku úplně jinou a pak by spuštění programu reálně způsobilo něco úplně jiného. To se myslím snažil Radek říct tím http://forum.root.cz/index.php?topic=11417.msg135027#msg135027

Jenže vlastnosti sémantiky ("runtimu") a vlastnosti jazyka jsou dvě různé věci. Typový systém je záležitostí jazyka. Souběhy a jejich důsledky jsou záležitostí sémantiky. Aspoň myslím teda

Pokud ti jazyk zakazuje souběh, tak ho runtime nemůže udělat. Pokud jazyk nespecifikuje takovou situaci, pak ano.

Nerozumím tomu, jak by mohl mět jeden jazyk více sémantik (významů výrazů)? Můžeš to rozvést?

1903

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 01:43:04 »

To sice ano, ale smysluplnost jazyka je o tom, zda jej lze interpretovat. Pokud to chcete uzavřít s tím, že Haskell je pure, ale nemáme pro něj pure kompilátor, tak fajn.

Purity je ale vlastnost JAZYKA, ničeho jinýho! V tomhle podle mě děláš v té úvaze chybu a zavádí tě to do nesmyslné* úvahy. Viz http://forum.root.cz/index.php?topic=11417.msg135038#msg135038

* to nemyslím pejorativně, rozumíme si doufám

Možná.

Má prvotní motivace proč jsem se začal zajímat o Haskell, byl jeho silný typový systém. Což si překládám tak, že když v jazyku řeknu, že to vrátí číslo, tak to vrátí číslo! A basta.

Takže si asi dokážeš představit, že mě moc netankuje když sice jazyk je pure, ale že kompilátor si dělá něco jiného je v pořádku.

1904

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 01:38:09 »

Heleďte, tak jinak: krom jiných nepopiratelných krás, nám funkcionální paradigma přináší snadnou implementaci paralelních výpočtů. Odvážil bych se prohlásit, že je to často ta primární motivace. Pokud ale do toho zamícháte IOMonády, tak opouštíte sluníčkový svět. IOMonády si s paralelizmem nekamarádí (ne, že by to nešlo), nepočítají s tím, a nepomůžou. Nepřijde vám to divný?

BTW i ten nesluníčkový svět se souběhy můžete matematicky popsat a tím se vlastně vrátit ke sluníčkovému světu. Například místo jednoho stavu světa budete pracovat s množinami všech možných stavů světa.

To by bylo ideální, ale pochopil jsem to (možná nesprávně), Haskellovský typový systém IO Monád na to nestačí.

Navážu na ten můj popis s těmi třemi příklady: Funkci openFile :: FilePath -> IOMode -> IO Handle si můžeme představit, že právě rozdvojí ten vnitřní svět na dva, na situaci, kdy se soubor podaří otevřít a na situaci, kdy to vyhodí chybu. Jestli to chápu dobře, tak toto nejde tak úplně substituovat, ale čert to vem. Ale jak by se dal něčím takovým eliminovat souběh?

1905

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 05. 07. 2015, 01:31:14 »

IO Monáda umožní souběh.

To s vhodnou interpretací umožní libovolný matematický objekt - třeba číslo 1.

No tak předpokládám, že to chceme implementovat tak aby to nešlo, ne aby to šlo.

Čistota jazyka nezávisí na tom, jak interpretujete výsledky programů.

To sice ano, ale smysluplnost jazyka je o tom, zda jej lze interpretovat. Pokud to chcete uzavřít s tím, že Haskell je pure, ale nemáme pro něj pure kompilátor, tak fajn.