Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: jouda 28. 06. 2015, 01:23:58
-
Dobry den, chci se zeptat jestli ma tady nekdo zkusenosti z implementaci byznys pozadavku ve funkcionalnich jazicich. Prave se nachazim na rozcesti, kdy si musim zvolit, jakym smerem se bude ubirat moje profesni kariera. Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu. Obavam se vsak, ze nebudu moci plne splynout se zelezem a pokrocile kapitoly jako memory management zustane pro mne zapovezeny. Krome toho mam jeste zkusenosti s vyvojovym prostredim Turbo Pascal. V kostce - co obnasi funkcionalni programovani, pomineme li oscilacni charakteristiky?
-
Odpovědi na své otázky najdeš v tomto evangeliu: http://www.pismak.cz/index.php?data=read&id=247187
-
Sice LISP není funkcionální, a ne, ani clojure není, ale jinak pravdivé a smutné. Memory management je impure, od toho je GC. Pokud potřebuješ paradigma s vysokou abstrakcí, vem si FP, v opačném případě zůstaň u OOP.
-
Dobry den, chci se zeptat jestli ma tady nekdo zkusenosti z implementaci byznys pozadavku ve funkcionalnich jazicich. Prave se nachazim na rozcesti, kdy si musim zvolit, jakym smerem se bude ubirat moje profesni kariera. Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu. Obavam se vsak, ze nebudu moci plne zplynot se zelezem a pokrocile kapitoly jako memory management zustane pro mne zapovezeny. Krome toho mam jeste zkusenosti s vyvojovym prostredim Turbo Pascal. V kostce - co obnasi funkcionalni programovani, pomineme li oscilacni charakteristiky?
Tak stale si muzes vybrat jazyk, ktery podporuje vice paradigmat (OOP, FP ...). Me osobne ciste FP nevyhovuje a ciste OOP taky ne. Proto mam rad jazyky, ktere me nenuti do jednoho ci druheho.
-
Dobry den, chci se zeptat jestli ma tady nekdo zkusenosti z implementaci byznys pozadavku ve funkcionalnich jazicich. Prave se nachazim na rozcesti, kdy si musim zvolit, jakym smerem se bude ubirat moje profesni kariera. Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu. Obavam se vsak, ze nebudu moci plne zplynot se zelezem a pokrocile kapitoly jako memory management zustane pro mne zapovezeny. Krome toho mam jeste zkusenosti s vyvojovym prostredim Turbo Pascal. V kostce - co obnasi funkcionalni programovani, pomineme li oscilacni charakteristiky?
Tak stale si muzes vybrat jazyk, ktery podporuje vice paradigmat (OOP, FP ...). Me osobne ciste FP nevyhovuje a ciste OOP taky ne. Proto mam rad jazyky, ktere me nenuti do jednoho ci druheho.
Kočkopsy mají nevýhodu ve funkcionalite. Pokud paradigmata mají vzájemně neslučitelné vlastnosti, musí se tyto vlastnosti ve jménu koexistence potlačit. A tím znehodnotime daná paradigmata. Výsledek? Multiparadigmatické jazyky jsou obvykle prasarna, ale ne vždy, zvláště pokud zkombinovana paradigmata patří do stejné rodiny. Kupříkladu mix reaktivního a funkcionalního paradigmatu je úžasný a umožňuje nám dělat IO bez ztráty čistoty. Mix proceduralniho a funkcionalního paradigmatu je na druhou stranu katastrofální a silně FP znehodnocuje. Ano, mluvím o scale. Scala je přesně takový kočkopes. A že je objektová? Ne není, v dnešní době není objektové nic, skončilo to smalltalkem. Dnešní oop jazyky sou procedurální jazyky s troškou syntaktickeho cukru aby to vypadalo jak posílání zpráv.
-
co maju vsetci furt s tym smalltalkom?
-
No co by měli šeci s tým smalltalkem - myslíja si, že nikde sa nepoužívá konstrukce známá z qt:
connect(odkud, SIGNAL(funkce()), kam, SLOT(funkce), Qt::QueuedConnection);
...teoretici
-
"Dnešní oop jazyky sou procedurální jazyky"
Desítky let vývoje, desetitisíce vývojářů ... a přitom - stačilo se zeptat prvního českého burana, který by hned věděl jak je všechno blbě a co a jak má být ..
-
Dnešní oop jazyky sou procedurální jazyky s troškou syntaktickeho cukru aby to vypadalo jak posílání zpráv.
ano, a?
mozete sediet doma pri pive a robit while(true) printf("svet ide do zadeke")
svetu vladne oop ako videne v jave/.net, pripadne multiparadigmaticky gulas ako javascript ci scala alebo v sucasnosti nahypovana vzbura ... clojure. (na smalltalk sa spomina pri vatre)
ano java oop je proceduralne aby ste ho mohli pouzivat ako stateless a teda pseudo funkcionalne
-
No co by měli šeci s tým smalltalkem - myslíja si, že nikde sa nepoužívá konstrukce známá z qt:
connect(odkud, SIGNAL(funkce()), kam, SLOT(funkce), Qt::QueuedConnection);
...teoretici
A se Smalltalkem to souvisí jak? Už teď mám takový pocit, že tvá odpověď mi vykouzlí úsměv na rtech.
-
No jak... nijak. Stejně jako smalltalk nesouvisí s funkcionálním programováním - to jest s původním dotazem, a stejně jako
nesouvisí s množstvím dalších dotazů, na které nějaký místní purista odpoví "jediný objektový jazyk je smalltalk, vše ostatní
je syntaktické pozlátko".
Posílání zpráv z objektu do objektu dneska opravdu není zvykem - jako jednodušší a praktičtější se prosadilo něco jiného.
Ale podobné mechanismy existují a hojně se používají, ač teď nejsou právě součástí jazyka.
-
Na funkcionalnich jazycich mi imponuje obzvlaste esteticnost a udrzovatelnost kodu.
Čistě funkcionální programátor neexistuje, vždy budeš muset aktivně umět několik dalších jazyků a paradigmat, to proto že funkcionální hardware neexistuje, existuje pouze hardware imperativní.
Estetičnost a udržovatelnost funkcionálních kódu je obecně oblíbený omyl, realita je mnohem horší než všechny očekávání, viz zde:
http://augustss.blogspot.cz/2007/08/quicksort-in-haskell-quicksort-is.html
http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort
-
No jak... nijak. Stejně jako smalltalk nesouvisí s funkcionálním programováním - to jest s původním dotazem, a stejně jako
nesouvisí s množstvím dalších dotazů, na které nějaký místní purista odpoví "jediný objektový jazyk je smalltalk, vše ostatní
je syntaktické pozlátko".
Posílání zpráv z objektu do objektu dneska opravdu není zvykem - jako jednodušší a praktičtější se prosadilo něco jiného.
Ale podobné mechanismy existují a hojně se používají, ač teď nejsou právě součástí jazyka.
No ale - a co? Smalltalk, Self, Objective C, Ruby, do jisté míry i Java a jistě by se našly další objektové jazyky. Objektové programování jeho autor definoval jako model založený na uzavřených funkčních entitách uchovávajících svůj stav, vzájemně komunikujících zprávami a na polymorfismu dosaženém pozdní vazbou. Sám autor pojmu objektově orientované programování se podivuje nad tím, jak je možné, že to tolik lidí nebylo schopno pochopit. Takže z tohoto hlediska je názor některých lidí na některé "objektové" jazyky pochopitelný. Stačí porovnat, jak se dá v takovém Smalltalku nebo Objective C kouzlit s objekty třeba s Javou nebo dokonce C++ aby člověku hned bylo jasné, co je podstatou objektového programování. Když někdo začne dávat funkce do struktur, které přejmenuje na "class" a umožní od nich odvozovat další struktury, tak to prostě nestačí. To je pořád jen staré známé strukturované programování, není důvod tomu říkat jinak, protože oproti němu nepřináší vůbec nic nového. To by bylo totéž, jako nazývat parní stroj turbinou jen kvůli tomu, že ho dělíte na vysokotlakou a nízkotlakou část. To prostě nestačí, turbina funguje na trochu jiném principu.
-
Posílání zpráv z objektu do objektu dneska opravdu není zvykem - jako jednodušší a praktičtější se prosadilo něco jiného.
To mi vysvětli. Posílání zpráv v OOP dělám běžně.
-
Objektové programování jeho autor definoval jako model založený na uzavřených funkčních entitách uchovávajících svůj stav, vzájemně komunikujících zprávami a na polymorfismu dosaženém pozdní vazbou. Sám autor pojmu objektově orientované programování se podivuje nad tím, jak je možné, že to tolik lidí nebylo schopno pochopit.
Původní OOP pochopí každý za 5 minut, je to asynchronní zasílání zpráv procesům a hledání metod podle názvu. Původní koncept OOP se používá tam kde je jeho místo a to v inter-process komunikaci. Dnešní OOP je úplně něco jiného protože řeší úplně jiné problémy.
-
To mi vysvětli. Posílání zpráv v OOP dělám běžně.
Ale to nesmíš! Na posílání zpráv je tady SmallTalk, všechny ostatní objektové jazyky jsou procedurální.
-
Objektové programování jeho autor definoval jako model založený na uzavřených funkčních entitách uchovávajících svůj stav, vzájemně komunikujících zprávami a na polymorfismu dosaženém pozdní vazbou. Sám autor pojmu objektově orientované programování se podivuje nad tím, jak je možné, že to tolik lidí nebylo schopno pochopit.
Původní OOP pochopí každý za 5 minut, je to asynchronní zasílání zpráv procesům a hledání metod podle názvu. Původní koncept OOP se používá tam kde je jeho místo a to v inter-process komunikaci. Dnešní OOP je úplně něco jiného protože řeší úplně jiné problémy.
Proč se tomu teda říká OOP, když to nemá s OOP téměř nic společného? A jaké problémy řeší? Mimochodem – na „původním” modelu OOP je založeno třeba Cocoa. Když má z něho člověk po půlročním projektu přejít zase třeba na MFC, tak si připadá, jako kdyby se vrátil někam do doby kamenné.
-
"Dnešní oop jazyky sou procedurální jazyky"
Desítky let vývoje, desetitisíce vývojářů ... a přitom - stačilo se zeptat prvního českého burana, který by hned věděl jak je všechno blbě a co a jak má být ..
Vole, když nesouhlasíš s mým názorem, oponuj nějakou myšlenkou. Jediný český buran si tady ty. "všichni říkají že mlátit ženy je dobré, a ty, ty si debil protože jediný říkáš že to není pravda". Nebo jiný příklad chceš? Argumentovat že když to říkají/dělají všichni, tak je to nepochybně správně je na úrovni základní školy.
-
Dnešní oop jazyky sou procedurální jazyky s troškou syntaktickeho cukru aby to vypadalo jak posílání zpráv.
ano, a?
mozete sediet doma pri pive a robit while(true) printf("svet ide do zadeke")
svetu vladne oop ako videne v jave/.net, pripadne multiparadigmaticky gulas ako javascript ci scala alebo v sucasnosti nahypovana vzbura ... clojure. (na smalltalk sa spomina pri vatre)
ano java oop je proceduralne aby ste ho mohli pouzivat ako stateless a teda pseudo funkcionalne
Eh, teda hmm. No. Vysvětli mi poslední větu prosím. Jedna moje polovina je strašně zvědavá na to, co se dozví, a ta druhá to ani nechce vědět.
-
OOP i FP paradigmata trpí tím, že valná většina programátorů neví o co vůbec jde a s klidným svědomím řekne že C++/Java/C#/Python/... implementují OOP a zároveň i FP. Přitom dané jazyky neimplementují ani jedno. Korunu tomu poté dá hláška kterou jsem měl čest slyšet: "jo jazyk XYZ je funkcionální, jsou v něm taky ty funkce ...". Super, jsou tam funkce, je to funkcionální ...
Jako, je mi to trošku líto, vůbec jsem nechtěl odvést vlákno na Smalltalk, pouze sem ale nechtěl aby na mne skočil někdo s tím, že přece Scala nekombinuje deklarativnost a imperativnost protože OOP není imperativní. Ne není. Ale to dnešní jo.
-
Proč se tomu teda říká OOP, když to nemá s OOP téměř nic společného? A jaké problémy řeší? Mimochodem – na „původním” modelu OOP je založeno třeba Cocoa. Když má z něho člověk po půlročním projektu přejít zase třeba na MFC, tak si připadá, jako kdyby se vrátil někam do doby kamenné.
S původním významem OOP nemá společného prakticky nic, ani Smalltalk ani Cocoa.
Původní OOP je o zasílání asynchronních zpráv samostatně fungujícím jednotkám jako třeba počítač, proces, vlákno, to vše s pozdní vazbou.
-
Proč se tomu teda říká OOP, když to nemá s OOP téměř nic společného? A jaké problémy řeší? Mimochodem – na „původním” modelu OOP je založeno třeba Cocoa. Když má z něho člověk po půlročním projektu přejít zase třeba na MFC, tak si připadá, jako kdyby se vrátil někam do doby kamenné.
S původním významem OOP nemá společného prakticky nic, ani Smalltalk ani Cocoa.
Původní OOP je o zasílání asynchronních zpráv samostatně fungujícím jednotkám jako třeba počítač, proces, vlákno, to vše s pozdní vazbou.
To je naprostý nesmysl.
To, co píšeš, je pouhá IPC a to s objektově orientovaným programováním nijak nesouvisí. Pojem „Object Oriented Programming” zavedl Alan C. Kay a ten tím rozhodně nemyslel to, co jsi napsal – viz veřejně dostupné zdroje.
-
To je naprostý nesmysl.
To, co píšeš, je pouhá IPC a to s objektově orientovaným programováním nijak nesouvisí. Pojem „Object Oriented Programming” zavedl Alan C. Kay a ten tím rozhodně nemyslel to, co jsi napsal – viz veřejně dostupné zdroje.
Původní OOP je to čemu se dneska říká IPC, konečně se v tom začínáte orientovat :D Veřejně dostupné zdroje to potvrzují:
- I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
-
To je naprostý nesmysl.
To, co píšeš, je pouhá IPC a to s objektově orientovaným programováním nijak nesouvisí. Pojem „Object Oriented Programming” zavedl Alan C. Kay a ten tím rozhodně nemyslel to, co jsi napsal – viz veřejně dostupné zdroje.
Původní OOP je to čemu se dneska říká IPC, konečně se v tom začínáte orientovat :D Veřejně dostupné zdroje to potvrzují:
- I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
Aha, no už mi je konečně jasné, odkud se vzala ta vaše popletenost. :) Připomínáte mi režiséra Kohoutka ve filmu Trhák, jak vždycky nějakou scénu ve scénáři špatně pochopí a začne ji realizovat doslova: „Listonoška se nemůže odtrhnout od okna.” – Pro Krista pána! Takhle já jsem to nemyslel! Pohledem se nemůže odtrhnout, to se přece tak říká… – Ale vy jste tam speciálně vypíchnul to lepidlo! – Já jsem nic nevypichoval, jen jsem prostě popsal normální rekvizity přítomné na každé poště.
Takže zdroj jste četl dobrý, teď ještě zapracovat na čtení textu s porozuměním, v tomto případě doporučuji zamyslet se nad významem slovíčka like. ;)
-
OOP i FP paradigmata trpí tím, že valná většina programátorů neví o co vůbec jde a s klidným svědomím řekne že C++/Java/C#/Python/... implementují OOP a zároveň i FP. Přitom dané jazyky neimplementují ani jedno. Korunu tomu poté dá hláška kterou jsem měl čest slyšet: "jo jazyk XYZ je funkcionální, jsou v něm taky ty funkce ...". Super, jsou tam funkce, je to funkcionální ...
Jako, je mi to trošku líto, vůbec jsem nechtěl odvést vlákno na Smalltalk, pouze sem ale nechtěl aby na mne skočil někdo s tím, že přece Scala nekombinuje deklarativnost a imperativnost protože OOP není imperativní. Ne není. Ale to dnešní jo.
Takze podle tebe jsou to vse jen proceduralni jazyky ?
Nebo to nejsou jazyky vubec ?
-
Drazí odborníci, docela by mě zajímalo, zda lze například concurrent assignments ve VHDL považovat za funkcionální prvek. Zvláště pak pokud výstupem kompilace (resp. syntézy) není program, ale zapojení.
a <= b or c;
d <= a and not e;
-
OOP i FP paradigmata trpí tím, že valná většina programátorů neví o co vůbec jde a s klidným svědomím řekne že C++/Java/C#/Python/... implementují OOP a zároveň i FP. Přitom dané jazyky neimplementují ani jedno. Korunu tomu poté dá hláška kterou jsem měl čest slyšet: "jo jazyk XYZ je funkcionální, jsou v něm taky ty funkce ...". Super, jsou tam funkce, je to funkcionální ...
Jako, je mi to trošku líto, vůbec jsem nechtěl odvést vlákno na Smalltalk, pouze sem ale nechtěl aby na mne skočil někdo s tím, že přece Scala nekombinuje deklarativnost a imperativnost protože OOP není imperativní. Ne není. Ale to dnešní jo.
Takze podle tebe jsou to vse jen proceduralni jazyky ?
Nebo to nejsou jazyky vubec ?
Ano. Méně jízlivosti a více myšlení prosím. Než ale budeš zběsile psát nějakou odpověď postrádající SMYSLUPLNÝ argument, prosím, nastuduj si něco o paradigmatech či paradigmatu, o kterém chceš diskutovat. Fakt není možný vést diskuzi s lidmi, kteří vlastně ani nevědí o co jde, jen je sere člověk kterej jim boří představu o jejich jazyku/paradigmatu.
"COŽE, OOP není OOP? To není pravda, vždyť tady se píše že je, přesně v tédle knize o C++/Javě/Pythonu/jáNevímČehoJeště! Na hranici s ním! Heretik!"
-
Drazí odborníci, docela by mě zajímalo, zda lze například concurrent assignments ve VHDL považovat za funkcionální prvek. Zvláště pak pokud výstupem kompilace (resp. syntézy) není program, ale zapojení.
a <= b or c;
d <= a and not e;
VHDL implementuje reaktivní paradigma. Dokonce mám pocit že zrod reaktivního paradigmatu se datuje od vzniku jazyků pro návrh EL zapojení. Takže VHDL je deklarativní jazyk.
Funkcionální prvek je vše co splňuje podmínku referenční transparentnosti. Řečeno jinak, při stejném vstupu vrátí funkce (či "něco" co funkce popisuje) stejný výsledek, je jedno kolikrát a kdy ji vyhodnocujeme (či posíláme "tomu něčemu" data).
-
OOP i FP paradigmata trpí tím, že valná většina programátorů neví o co vůbec jde a s klidným svědomím řekne že C++/Java/C#/Python/... implementují OOP a zároveň i FP. Přitom dané jazyky neimplementují ani jedno.
Tak treba podle me jazyk D implementuje castecne OOP i funkcionalni programovani a samozrejme i proceduralni. Ano nekdo by to nazval za zmrseni techto paradigmat ja tomu rikam idealni jazyk, protoze mi umoznuje delat vse co potrebuji zpusobem ktery me vyhovuje.
Korunu tomu poté dá hláška kterou jsem měl čest slyšet: "jo jazyk XYZ je funkcionální, jsou v něm taky ty funkce ...". Super, jsou tam funkce, je to funkcionální ...
Jo toto je(byl) bohuzel casty omyl, nastesti diky osvete uz se to uz zlepsilo. Priznam se ze jako dite jsem si to taky myslel.
-
VHDL implementuje reaktivní paradigma. Dokonce mám pocit že zrod reaktivního paradigmatu se datuje od vzniku jazyků pro návrh EL zapojení. Takže VHDL je deklarativní jazyk.
Funkcionální prvek je vše co splňuje podmínku referenční transparentnosti. Řečeno jinak, při stejném vstupu vrátí funkce (či "něco" co funkce popisuje) stejný výsledek, je jedno kolikrát a kdy ji vyhodnocujeme (či posíláme "tomu něčemu" data).
O reaktivním paradigmatu slyším prvně. Měl bys nějaký relevantní link?
-
VHDL implementuje reaktivní paradigma. Dokonce mám pocit že zrod reaktivního paradigmatu se datuje od vzniku jazyků pro návrh EL zapojení. Takže VHDL je deklarativní jazyk.
Funkcionální prvek je vše co splňuje podmínku referenční transparentnosti. Řečeno jinak, při stejném vstupu vrátí funkce (či "něco" co funkce popisuje) stejný výsledek, je jedno kolikrát a kdy ji vyhodnocujeme (či posíláme "tomu něčemu" data).
O reaktivním paradigmatu slyším prvně. Měl bys nějaký relevantní link?
Tak nakonec google umím použít, tak netřeba, díky.
-
OOP i FP paradigmata trpí tím, že valná většina programátorů neví o co vůbec jde a s klidným svědomím řekne že C++/Java/C#/Python/... implementují OOP a zároveň i FP. Přitom dané jazyky neimplementují ani jedno.
Tak treba podle me jazyk D implementuje castecne OOP i funkcionalni programovani a samozrejme i proceduralni. Ano nekdo by to nazval za zmrseni techto paradigmat ja tomu rikam idealni jazyk, protoze mi umoznuje delat vse co potrebuji zpusobem ktery me vyhovuje.
Totéž mohu tvrdit o PHP. Multiparadigmatické jazyky budou tím, co si z nich uděláme.
-
VHDL implementuje reaktivní paradigma. Dokonce mám pocit že zrod reaktivního paradigmatu se datuje od vzniku jazyků pro návrh EL zapojení. Takže VHDL je deklarativní jazyk.
Funkcionální prvek je vše co splňuje podmínku referenční transparentnosti. Řečeno jinak, při stejném vstupu vrátí funkce (či "něco" co funkce popisuje) stejný výsledek, je jedno kolikrát a kdy ji vyhodnocujeme (či posíláme "tomu něčemu" data).
O reaktivním paradigmatu slyším prvně. Měl bys nějaký relevantní link?
https://en.wikipedia.org/wiki/Reactive_programming. Pokud chceš vyzkoušet, hrr na http://elm-lang.org/. Je to FRP (mix reaktivity a funkcionality). Fakt hezký jazyk, jeden z mála skutečně čistých funkcionálních jazyků (čistý z 99%, bohužel s maličkou vyjímkou, ale opravdu jen maličkou, způsobenou špatným návrhem jazyka, nikoli použitých paradigmat). Bohužel, je hodně nedodělaný, spíš hračka. Ale na vyzkoušení principu je úžasný.
-
Estetičnost a udržovatelnost funkcionálních kódu je obecně oblíbený omyl, realita je mnohem horší než všechny očekávání, viz zde:
http://augustss.blogspot.cz/2007/08/quicksort-in-haskell-quicksort-is.html
http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort
No já nevím, je sice asi pravda, že funkcionální programování není všelék, který vyřeší všechny problémy vývoje aplikací, ale argumentovat tím, že učebnicový QuickSort z první kapitoly většiny tutoriálů k Haskellu není "pravý QuickSort" a aby byl, muselo by se z Haskellu stát de facto C, také není moc fér.
-
VHDL implementuje reaktivní paradigma. Dokonce mám pocit že zrod reaktivního paradigmatu se datuje od vzniku jazyků pro návrh EL zapojení. Takže VHDL je deklarativní jazyk.
Funkcionální prvek je vše co splňuje podmínku referenční transparentnosti. Řečeno jinak, při stejném vstupu vrátí funkce (či "něco" co funkce popisuje) stejný výsledek, je jedno kolikrát a kdy ji vyhodnocujeme (či posíláme "tomu něčemu" data).
O reaktivním paradigmatu slyším prvně. Měl bys nějaký relevantní link?
https://en.wikipedia.org/wiki/Reactive_programming
-
OOP i FP paradigmata trpí tím, že valná většina programátorů neví o co vůbec jde a s klidným svědomím řekne že C++/Java/C#/Python/... implementují OOP a zároveň i FP. Přitom dané jazyky neimplementují ani jedno.
Tak treba podle me jazyk D implementuje castecne OOP i funkcionalni programovani a samozrejme i proceduralni. Ano nekdo by to nazval za zmrseni techto paradigmat ja tomu rikam idealni jazyk, protoze mi umoznuje delat vse co potrebuji zpusobem ktery me vyhovuje.
Totéž mohu tvrdit o PHP. Multiparadigmatické jazyky budou tím, co si z nich uděláme.
Tak to zase nee, :D. PHP je vyjimka, ackoliv je to jeden z mych oblibenych jazyku a zivi me, tak OOP je tam znacne omezene a funkcionalni programovani tam imho neexistuje.
Even php coder can become a programmer. And programmer can
become D programmer
-
Totéž mohu tvrdit o PHP. Multiparadigmatické jazyky budou tím, co si z nich uděláme.
Tak to zase nee, :D. PHP je vyjimka, ackoliv je to jeden z mych oblibenych jazyku a zivi me, tak OOP je tam znacne omezene a funkcionalni programovani tam imho neexistuje.
Povídej, co z toho PHP neumí.
-
Povídej, co z toho PHP neumí.
Koukal jsem a z FP toho umí celkem dost. :) Uzávěry, funkce jako plnotučné entity, částečná aplikace by se tam taky nějak dala spáchat. Akorát ty vedlejší efekty si musím hlídat. :(
-
Takže zdroj jste četl dobrý, teď ještě zapracovat na čtení textu s porozuměním, v tomto případě doporučuji zamyslet se nad významem slovíčka like. ;)
Není čemu nerozumět, význam samostatných počítačů v síti jasně koresponduje s požadavkem na zasílání zpráv, které má smysl pouze v asynchronním prostředí, jako třeba dva a více počítačů v síti. V synchronním jednovláknovém prostředí potřebujete nanejvýš pozdní vazbu, ale už ne zasílání zpráv to je pak zbytečné.
-
Takže zdroj jste četl dobrý, teď ještě zapracovat na čtení textu s porozuměním, v tomto případě doporučuji zamyslet se nad významem slovíčka like. ;)
Není čemu nerozumět, význam samostatných počítačů v síti jasně koresponduje s požadavkem na zasílání zpráv, které má smysl pouze v asynchronním prostředí, jako třeba dva a více počítačů v síti. V synchronním jednovláknovém prostředí potřebujete nanejvýš pozdní vazbu, ale už ne zasílání zpráv to je pak zbytečné.
(http://www.blogcdn.com/massively.joystiq.com/media/2011/10/facepalm.jpg)
-
Totéž mohu tvrdit o PHP. Multiparadigmatické jazyky budou tím, co si z nich uděláme.
Tak to zase nee, :D. PHP je vyjimka, ackoliv je to jeden z mych oblibenych jazyku a zivi me, tak OOP je tam znacne omezene a funkcionalni programovani tam imho neexistuje.
Povídej, co z toho PHP neumí.
immutability, pure funkce napr. Samozrejme muzes namitat ze to jde i bez toho, ale to je uz pak o necem jinem :)
-
Povídej, co z toho PHP neumí.
Koukal jsem a z FP toho umí celkem dost. :) Uzávěry, funkce jako plnotučné entity, částečná aplikace by se tam taky nějak dala spáchat. Akorát ty vedlejší efekty si musím hlídat. :(
Nechci kazit iluzi, ale vše co jsi vyjmenoval nepatří mezi funkcionální prvky, jsou to prvky VYUŽÍVANÉ funkcionálním paradigmatem. Já nevím co je na tom tak těžkýho. Splňuje každá funkce jazyka referenční transparentnost a čistototu? Ne? Pak to nebude funkcionální jazyk.
Víš proč se v dnešní době říká některým jazyků funkcionální, a jiným čistě funkcionální? Protože v historii bylo opravdu hodně blbů kteří jakmile viděly lambda funkci (či vůbec jakoukoli funkci ...) začali křičet: "Juuu funkcionální jazyk". No, a tak se zavedl termín (pure FP) pro odlišení těch SKUTEČNĚ funkcionálních od toho špatně pochopeného zbytku.
Ale ne, bude se muset vymyslet ještě něco na způsob really pure FP, díky Haskellu, který na úplnou čistotu rezignoval, a zavedl systém částečné nečistoty, která, když má člověk smůlu na blbý typ aplikace, může tvořit i většinu kódu ...
-
Povídej, co z toho PHP neumí.
Koukal jsem a z FP toho umí celkem dost. :) Uzávěry, funkce jako plnotučné entity, částečná aplikace by se tam taky nějak dala spáchat. Akorát ty vedlejší efekty si musím hlídat. :(
systém částečné nečistoty
tím myslíte Control.Monad.ST?
-
Jo, nedopsal sem myšlenku, Haskell právě živí tu dezinformaci, protože funkcionální fakt není, ačkoli tvrdí že je pure FP, takže tadáááá, ať žije zmatek.
-
Povídej, co z toho PHP neumí.
Koukal jsem a z FP toho umí celkem dost. :) Uzávěry, funkce jako plnotučné entity, částečná aplikace by se tam taky nějak dala spáchat. Akorát ty vedlejší efekty si musím hlídat. :(
systém částečné nečistoty
tím myslíte Control.Monad.ST?
Tím myslím celou IO monádu ...
-
ALE proboha, tím neříkám že je Haskell špatný, osobně je to v aktuální chvíli můj nejoblíbenější jazyk (lepší ehm, zatím není). Pouze autoři tak trošku lžou.
-
Povídej, co z toho PHP neumí.
Koukal jsem a z FP toho umí celkem dost. :) Uzávěry, funkce jako plnotučné entity, částečná aplikace by se tam taky nějak dala spáchat. Akorát ty vedlejší efekty si musím hlídat. :(
systém částečné nečistoty
tím myslíte Control.Monad.ST?
Tím myslím celou IO monádu ...
i čistě funkcionální jazyk potřebuje vstup a výstup, jak byste to řešil vy?
-
Povídej, co z toho PHP neumí.
Koukal jsem a z FP toho umí celkem dost. :) Uzávěry, funkce jako plnotučné entity, částečná aplikace by se tam taky nějak dala spáchat. Akorát ty vedlejší efekty si musím hlídat. :(
systém částečné nečistoty
tím myslíte Control.Monad.ST?
Tím myslím celou IO monádu ...
i čistě funkcionální jazyk potřebuje vstup a výstup, jak byste to řešil vy?
Nooo, zkusil bych se dát na ZEN.
Blbej vtip ...
Ve zkratce. Uniqueness typing. Používá ho Clean a ještě jedna potvora. Bohužel, obědvě potvory jsou bez komunity (větší), a bez prostředí (které tvoří komunita), takže jsou bohužel k nepotřebě. Kdyby nebyl Haskell, je dost možné, že by to bylo jinak, protože by měli komunitu starající se o jejich vývoj. Ale Haskell je prostě good enough, zatím.
Další metoda, zkombinování reaktivního paradigmatu s FP, geniální a jednoduché. Opět stejný problém jako u minulé metody. Existuje pouze jeden jediný FRP jazyk o kterým vím, a je to bohužel nedodělaná hračka.
A ještě jedna metoda. Využívá lazy evaluation. Prostě jako vstup vezmeme nekonečný list zpráv, a program posílá běhovému prostědí nekonečný list odpovědí. Hezké, ale žádný jazyk to dosud nevyzkoušel, lze ale na tento nápad narazit na internetu když člověk hledá.
-
Tím myslím celou IO monádu ...
Ale IO monad je čistě funkcionální. Vždyť je to jen syntaktický cukříček nad tím, že každá io funkce bere RealWorld a vrací jeho novou verzi. No a pokud je svět kolem tebe vždy zničen a vytvořen nový, tak to vypadá jako by existovaly nějaké vedlejší efekty. Samozřejmě je to pouze iluze 8)
A teď bez zadeke. Každý jazyk který má být k něčemu dobrý musí umět vedlejší efekty. Prostě proto, že modifikace okolí je obvyklá úloha SW. Tvrdit, že nejaký jazyk není úplně čistý je to samé jako tvrdit, že není úplně nepoužitelný.
-
A teď bez zadeke.
WTF :o CenzorBot? Si někdo dělá perdel, ne?
-
ALE proboha, tím neříkám že je Haskell špatný, osobně je to v aktuální chvíli můj nejoblíbenější jazyk (lepší ehm, zatím není). Pouze autoři tak trošku lžou.
Autoři nelžou, jen zřejmě používají jinou definici než vy.
Například s následující definicí „výraz e je referenčně transparentní, pokud mohu v každém programu nahradit libovolné výskyty e hodnotou e a chování programu se nezmění. “ dostanete, že výrazy v Haskellu (kromě výrazů používajících unsafePerformIO apod.) jsou referenčně transparentní včetně výrazů typu IO x pro nějaké x.
-
Tím myslím celou IO monádu ...
Ale IO monad je čistě funkcionální. Vždyť je to jen syntaktický cukříček nad tím, že každá io funkce bere RealWorld a vrací jeho novou verzi. No a pokud je svět kolem tebe vždy zničen a vytvořen nový, tak to vypadá jako by existovaly nějaké vedlejší efekty. Samozřejmě je to pouze iluze 8)
A teď bez zadeke. Každý jazyk který má být k něčemu dobrý musí umět vedlejší efekty. Prostě proto, že modifikace okolí je obvyklá úloha SW. Tvrdit, že nejaký jazyk není úplně čistý je to samé jako tvrdit, že není úplně nepoužitelný.
Taaakže, pro skutečně čisté metody IO si přečti můj komentář přesně nad tím tvým.
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
-
A teď bez zadeke.
WTF :o CenzorBot? Si někdo dělá perdel, ne?
Jo, je tady, ale kurva, ještě ho musej zlepšit ...
-
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
Nesouhlasím, IMO vůbec to s tím nesouvisí.
-
ALE proboha, tím neříkám že je Haskell špatný, osobně je to v aktuální chvíli můj nejoblíbenější jazyk (lepší ehm, zatím není). Pouze autoři tak trošku lžou.
Autoři nelžou, jen zřejmě používají jinou definici než vy.
Například s následující definicí „výraz e je referenčně transparentní, pokud mohu v každém programu nahradit libovolné výskyty e hodnotou e a chování programu se nezmění. “ dostanete, že výrazy v Haskellu (kromě výrazů používajících unsafePerformIO apod.) jsou referenčně transparentní včetně výrazů typu IO x pro nějaké x.
Ne ... už jsem UNAVENÝ z vysvětlování tadytoho, fakt, idioti, akorát rozšířili další dezinformaci o FP. Než začneš kecat něco o mí definici FP, přečti si v mých komentářích moji definici, a zjistíš, že je stejná jako je definice matematické funkce (tj. funkcionálního jazyka).
-
Uniqueness typing.
nemám nastudováno, pokusím se to napravit
A ještě jedna metoda. Využívá lazy evaluation. Prostě jako vstup vezmeme nekonečný list zpráv, a program posílá běhovému prostědí nekonečný list odpovědí. Hezké, ale žádný jazyk to dosud nevyzkoušel, lze ale na tento nápad narazit na internetu když člověk hledá.
myslím, že jsem na to narazil v sekci 7 paperu "History of Haskell: Being Lazy With Class", zmiňuje i Uniqueness typing
za sebe bych řekl, že Haskell je "pure", nemonadické funkce čisté jsou, monadické funkce dávají stejný výsledek ve stejném "prostředí" a se stejnými argumenty
-
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
Nesouhlasím, IMO vůbec to s tím nesouvisí.
Naneštěstí souvisí. Promiň, ale nechápeš o co vlastně ve FP jde. Další diskuze je bohužel s tebou nemožna :(
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
A Haskell ? Pomocí "čistého" IO se dělá race condition jedna báseň ...
-
Než začneš kecat něco o mí definici FP, přečti si v mých komentářích moji definici, a zjistíš, že je stejná jako je definice matematické funkce (tj. funkcionálního jazyka).
Pak tu definici zřejmě jen špatně používáte. Už jsme to mj. řešili v diskuzi na AbcLinuxu (http://www.abclinuxu.cz/blog/radekm/2015/3/async-a-await-je-krok-spatnym-smerem#35).
-
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
Nesouhlasím, IMO vůbec to s tím nesouvisí.
Naneštěstí souvisí. Promiň, ale nechápeš o co vlastně ve FP jde. Další diskuze je bohužel s tebou nemožna :(
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
A Haskell ? Pomocí "čistého" IO se dělá race condition jedna báseň ...
který systém vstupu/výstupu zamezuje vzniku race condition? IMHO to nelze
-
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
Race condition mohu dělat i pomocí data Write = Write Int - stačí vzít vhodný interpretr, co při interpretaci Write 1 a Write 2 udělá race condition. Samotné Write 1 však žádný vedlejší efekt nedělá. Haskell je podobný - IO žádný vedlejší efekt nedělá, dělá to až jakýsi interpretr - ale k němu nemáte v jazyce přístup - v tom je celý vtip.
-
Uniqueness typing.
nemám nastudováno, pokusím se to napravit
A ještě jedna metoda. Využívá lazy evaluation. Prostě jako vstup vezmeme nekonečný list zpráv, a program posílá běhovému prostědí nekonečný list odpovědí. Hezké, ale žádný jazyk to dosud nevyzkoušel, lze ale na tento nápad narazit na internetu když člověk hledá.
myslím, že jsem na to narazil v sekci 7 paperu "History of Haskell: Being Lazy With Class", zmiňuje i Uniqueness typing
za sebe bych řekl, že Haskell je "pure", nemonadické funkce čisté jsou, monadické funkce dávají stejný výsledek ve stejném "prostředí" a se stejnými argumenty
Monády nejsou "nečisté". To je taky jedna z mýlek. Pouze IO monáda. Koukni se na metody které jsem napsal, a pak si zkus udělat race condition v Haskellu (a použij IORef, MVar a TVar mají atomický zamykání a právě FP zamykat díky svým vlastnostem nepotřebuje), řekl bych, že brzo to pure odmažeš.
-
Tohle Vám nepomůže, prostě se v tom zjevně neorientujete, základní definice neovládáte.
-
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
Race condition mohu dělat i pomocí data Write = Write Int - stačí vzít vhodný interpretr, co při interpretaci Write 1 a Write 2 udělá race condition. Samotné Write 1 však žádný vedlejší efekt nedělá. Haskell je podobný - IO žádný vedlejší efekt nedělá, dělá to až jakýsi interpretr - ale k němu nemáte v jazyce přístup - v tom je celý vtip.
V tom není vtip, je to k pláči. S neexistujícícm interpretrem si di tam kam slunce nesvítí ... :(
-
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
Nesouhlasím, IMO vůbec to s tím nesouvisí.
Naneštěstí souvisí. Promiň, ale nechápeš o co vlastně ve FP jde. Další diskuze je bohužel s tebou nemožna :(
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
A Haskell ? Pomocí "čistého" IO se dělá race condition jedna báseň ...
který systém vstupu/výstupu zamezuje vzniku race condition? IMHO to nelze
Lze, alespoň co se týče paměti ano.
-
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
Race condition mohu dělat i pomocí data Write = Write Int - stačí vzít vhodný interpretr, co při interpretaci Write 1 a Write 2 udělá race condition. Samotné Write 1 však žádný vedlejší efekt nedělá. Haskell je podobný - IO žádný vedlejší efekt nedělá, dělá to až jakýsi interpretr - ale k němu nemáte v jazyce přístup - v tom je celý vtip.
V tom není vtip, je to k pláči. S neexistujícícm interpretrem si di tam kam slunce nesvítí ... :(
S prvním tvrzením souhlasím, díky správnému interpretru je možné udělat race condition všude (ale proboha proč ... ?), trošku to ale nesouvisí s tématem ...
-
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
Nesouhlasím, IMO vůbec to s tím nesouvisí.
Naneštěstí souvisí. Promiň, ale nechápeš o co vlastně ve FP jde. Další diskuze je bohužel s tebou nemožna :(
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
A Haskell ? Pomocí "čistého" IO se dělá race condition jedna báseň ...
který systém vstupu/výstupu zamezuje vzniku race condition? IMHO to nelze
Lze, alespoň co se týče paměti ano.
1) "Clean" je neskutečně idiotský název pro cokoliv a pro programovací jazyk zvláště a neomlouvá ani to, že tenkrát ještě google nebyl
2) nezbytnou ingrediencí pro race condition je souběžnost vykonávání programů, má ten Clean vlákna?
3) příklad z https://en.wikipedia.org/wiki/Uniqueness_type mi přijde ekvivalentní s IO monádou, ve které se ovšem "prostředí" předá implicitně a "doImperativeReadLineSystemCall" zcela jistě pure není
-
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
No nevím. Když se kouknu kolem sebe tak vidím tří zadeke neperzistentních dat, které je třeba modifikovat. Takže co mám na výběr?
1) LALALA Svět je sluníčkový!!! ...
2) Řešit reálné problémy.
A IO monád mi umožňuje interagovat s nesluníčkovým světem a přitom tu interakci omezit na nutné minimum. Pokud vedlejší efekty vyšoupnu ven z jazyka, pak je budu muset řešit něčím mimo jazyk. Ale budu je muset řešit.
-
Tak, a až si to dočteš, odpověz mi na jednu maličkatou otázku. Funkcionální jazyk neumožňuje race condition. Souhlasíš s mým tvrzením?
Nesouhlasím, IMO vůbec to s tím nesouvisí.
Naneštěstí souvisí. Promiň, ale nechápeš o co vlastně ve FP jde. Další diskuze je bohužel s tebou nemožna :(
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
A Haskell ? Pomocí "čistého" IO se dělá race condition jedna báseň ...
který systém vstupu/výstupu zamezuje vzniku race condition? IMHO to nelze
Lze, alespoň co se týče paměti ano.
1) "Clean" je neskutečně idiotský název pro cokoliv a pro programovací jazyk zvláště a neomlouvá ani to, že tenkrát ještě google nebyl
2) nezbytnou ingrediencí pro race condition je souběžnost vykonávání programů, má ten Clean vlákna?
3) příklad z https://en.wikipedia.org/wiki/Uniqueness_type mi přijde ekvivalentní s IO monádou, ve které se ovšem "prostředí" předá implicitně a "doImperativeReadLineSystemCall" zcela jistě pure není
Jo, jméno má blbý. Souhlas.
Netuším, protože Clean nemá pořádnou standardní knihovnu, externí knihovny a všechny vlastnosti má jen na windows, tak jsem jen prostudoval syntaxi. Je to prostě zanedbaný jazyk.
Jednou si přečíst wiki stránku (a náhodou přeskočit první větu která ozřejmuje proč to vlastně funguje a jakou to má nevýhodu), a nekouknout se jak to vlastně funguje v nějakém jazyce je k ničemu. Napřed prosím plně pochop princip, a pak o něm diskutuj. Normálně bych začal vysvětlovat jak vlastně uniqueness typing funguje ALE, ne už jsem unavený, už jsem mockrát něco vysvětloval jen pro to aby to druhá strana vůbec nepřečetla a ani se nad tím nezamyslela.
-
D O P R D E L E
Ve FP nemůže být race condition, když jsou všechny data persistentní, a žádná funkce nemá side efekty kurva už !!!
No nevím. Když se kouknu kolem sebe tak vidím tří zadeke neperzistentních dat, které je třeba modifikovat. Takže co mám na výběr?
1) LALALA Svět je sluníčkový!!! ...
2) Řešit reálné problémy.
A IO monád mi umožňuje interagovat s nesluníčkovým světem a přitom tu interakci omezit na nutné minimum. Pokud vedlejší efekty vyšoupnu ven z jazyka, pak je budu muset řešit něčím mimo jazyk. Ale budu je muset řešit.
Jo, svět není sluníčkový, zvláště teď mám extra silný pocti tý nesluníčkovosti.
Co máš na výběr? Třeba přestat ignorovat co píšu a kouknout se na metody IO bez ztráty čistoty.
Jo, máš pravdu, pokud je vyšoupneš z jazyka, budeš je muset řešit něčím jiným. I to je cesta.
-
Lze, alespoň co se týče paměti ano.
A co všechny ostatní věci? Soubory, sockety, ostatní procesy, vzdálené stroje, ...? Paměť je skoro to nejjednodušší.
-
Jednou si přečíst wiki stránku (a náhodou přeskočit první větu která ozřejmuje proč to vlastně funguje a jakou to má nevýhodu), a nekouknout se jak to vlastně funguje v nějakém jazyce je k ničemu. Napřed prosím plně pochop princip, a pak o něm diskutuj. Normálně bych začal vysvětlovat jak vlastně uniqueness typing funguje ALE, ne už jsem unavený, už jsem mockrát něco vysvětloval jen pro to aby to druhá strana vůbec nepřečetla a ani se nad tím nezamyslela.
jo, možná nechápu
tvrdím, že jazyk s uniqness typing (dle examplu z wiki) je stejně "pure-dle čumila" jako jazyk s haskellovskou IO monádou, můžete to vyvráti?
-
Tohle Vám nepomůže, prostě se v tom zjevně neorientujete, základní definice neovládáte.
:D :D :D
Že by nějaký učitýlek z ostravské sorbony nebo něčeho v tom stylu? :)
No, dívejme se na to pozitivně – místo odsuzování za to, že jste absolutně nepochopil pojem „zpráva” v objektově orientovaném jazyce a pod tím pojmem si dovedete představit jen zprávu IPC, buďme rádi, že se tu nehádáte o to, že zpráva je přeci to, co píšete do mobilu. :D
Tím bych to ze své strany uzavřel a doporučil Vám nějakou učebnici úplných základů objektově orientovaného programování, nejlépe od nějakého autora z prostředí otců-zakladatelů toho pojmu. Spaciálně bych si dal pozor na tituly českých autorů, protože mám někdy pocit, že čím méně toho dotyčný o dané problematice ví, tím větší má nutkání o tom psát knihy nebo aspoň skripta. A papír snese vše, jak známo.
howgh
-
Lze, alespoň co se týče paměti ano.
A co všechny ostatní věci? Soubory, sockety, ostatní procesy, vzdálené stroje, ...? Paměť je skoro to nejjednodušší.
... prosím, přečti si něco o těch metodách co jsem napsal, pochop je, zamysli se nad nimi, a pak zjistíš, že tato otázka a vlastně všechny v tomto vlákně jsou jasné.
-
Jednou si přečíst wiki stránku (a náhodou přeskočit první větu která ozřejmuje proč to vlastně funguje a jakou to má nevýhodu), a nekouknout se jak to vlastně funguje v nějakém jazyce je k ničemu. Napřed prosím plně pochop princip, a pak o něm diskutuj. Normálně bych začal vysvětlovat jak vlastně uniqueness typing funguje ALE, ne už jsem unavený, už jsem mockrát něco vysvětloval jen pro to aby to druhá strana vůbec nepřečetla a ani se nad tím nezamyslela.
jo, možná nechápu
tvrdím, že jazyk s uniqness typing (dle examplu z wiki) je stejně "pure-dle čumila" jako jazyk s haskellovskou IO monádou, můžete to vyvráti?
Jo ... můžu.
Ve zkratce. Uniqueness typing přidává do hry parametr času, není to moc vidět ale je to tak. V Haskellu parametr času není. Takže. Pokud máme objekt svět, pak v Haskellu nad tím jedním jedním objektem svět můžeme zavolat plno IO funkcí v různých vláknech, ty funkce vrátí svoje nové objekty svět a tak dál. Ve výsledku máme strašně moc objektů svět v jednu chvíli, a v různých vláknech. A tadá, race condition a nečistota.
A uniqueness typing? Kdyby sis pořádně přečetl tu wiki, už by ti to bylo jasný. Uniqueness objekt může mít za svůj život pouze jednu jedinou referenci na sebe. Takže, máme li objekt world, pak operace IO bere tento objekt world, a vrací nový, ale ten starý není možné použit více, reference se po jednom použití stala neplatnou, protože kdyby ne, začalo by na objekt ukazovat více referencí. Tím je zajištěna čistota, protože poté i IO funkce se stejnými argumenty vrátí stejný výsledek opakovaně, představ si to jako stroj času :). Nevýhoda je, že IO je možno realizovat pouze na jednom vlákně, a proto je mnohem lepší použít reaktivitu.
-
Jo ... můžu.
Ve zkratce. Uniqueness typing přidává do hry parametr času, není to moc vidět ale je to tak. V Haskellu parametr času není. Takže. Pokud máme objekt svět, pak v Haskellu nad tím jedním jedním objektem svět můžeme zavolat plno IO funkcí v různých vláknech, ty funkce vrátí svoje nové objekty svět a tak dál. Ve výsledku máme strašně moc objektů svět v jednu chvíli, a v různých vláknech. A tadá, race condition a nečistota.
tak má Clean vlákna nebo nemá? je nesmyslné takto porovnávat jazyk s vlákny a bez nich
máme li objekt world, pak operace IO bere tento objekt world, a vrací nový, ale ten starý není možné použit více, reference se po jednom použití stala neplatnou, protože kdyby ne, začalo by na objekt ukazovat více referencí. Tím je zajištěna čistota, protože poté i IO funkce se stejnými argumenty vrátí stejný výsledek opakovaně
tohle je prakticky popis IO monády, po provední vstupu/výstupu je starý "svět" již nedostupný a tudíž ho neleze znovu "použít"
-
... prosím, přečti si něco o těch metodách co jsem napsal, pochop je, zamysli se nad nimi, a pak zjistíš, že tato otázka a vlastně všechny v tomto vlákně jsou jasné.
Ano, čtu si, přemýšlím, nechápu.
Všechny ukázky unique typingu jako by z oka vypadly vnitřnostem IO monády. Snažil jsem se zjistit, jak se v Cleanu nebo v Mercury řeší vlákna. Chtěl jsem si porovnat Haskellovské problémy s IORef se stavem v Cleanu ale nic jsem nenašel. Vypadá to, že tam mám k dispozici jen skrytý thread pool a alternativu 'par'.
Pokud v Haskellu zakážu forkIO a pár dalších, tak mám taky vyřešené vedlejší efekty. Co mi uchází?
-
Vypadá to, že tam mám k dispozici jen skrytý thread pool a alternativu 'par'.
odkazy?
pár dalších
jméno té funkce je lepší ani nevyslovovat, i když je užitečná :D
-
Jo ... můžu.
Ve zkratce. Uniqueness typing přidává do hry parametr času, není to moc vidět ale je to tak. V Haskellu parametr času není. Takže. Pokud máme objekt svět, pak v Haskellu nad tím jedním jedním objektem svět můžeme zavolat plno IO funkcí v různých vláknech, ty funkce vrátí svoje nové objekty svět a tak dál. Ve výsledku máme strašně moc objektů svět v jednu chvíli, a v různých vláknech. A tadá, race condition a nečistota.
tak má Clean vlákna nebo nemá? je nesmyslné takto porovnávat jazyk s vlákny a bez nich
máme li objekt world, pak operace IO bere tento objekt world, a vrací nový, ale ten starý není možné použit více, reference se po jednom použití stala neplatnou, protože kdyby ne, začalo by na objekt ukazovat více referencí. Tím je zajištěna čistota, protože poté i IO funkce se stejnými argumenty vrátí stejný výsledek opakovaně
tohle je prakticky popis IO monády, po provední vstupu/výstupu je starý "svět" již nedostupný a tudíž ho neleze znovu "použít"
Netuším
lež! A už sem ti dokonce i vysvětlil nohoře jak funguje IO monáda! Aspoň si to přečti a zamysli se nad tím. Právě že ten starý svět lze použít opakovaně. A ve více vláknech.
-
... prosím, přečti si něco o těch metodách co jsem napsal, pochop je, zamysli se nad nimi, a pak zjistíš, že tato otázka a vlastně všechny v tomto vlákně jsou jasné.
Ano, čtu si, přemýšlím, nechápu.
Všechny ukázky unique typingu jako by z oka vypadly vnitřnostem IO monády. Snažil jsem se zjistit, jak se v Cleanu nebo v Mercury řeší vlákna. Chtěl jsem si porovnat Haskellovské problémy s IORef se stavem v Cleanu ale nic jsem nenašel. Vypadá to, že tam mám k dispozici jen skrytý thread pool a alternativu 'par'.
Pokud v Haskellu zakážu forkIO a pár dalších, tak mám taky vyřešené vedlejší efekty. Co mi uchází?
Uchází ti, že v Haskellu může v jednu chvíli být neomezené množství světů najednou, kdežto v Cleanu pouze jeden.
-
A díky jednomu jedinému světu je udržena časová konzistence a splněna referenční transparentnost.
-
No, dívejme se na to pozitivně – místo odsuzování za to, že jste absolutně nepochopil pojem „zpráva” v objektově orientovaném jazyce a pod tím pojmem si dovedete představit jen zprávu IPC
Naopak pochopil jsem to zcela jasně, objekt dle Kaye dostane zprávu a sám se rozhodne zda a jakou svoji metodu zavolá. U sousedů se tomuto mechanismu říká IPC, funkčnost je velmi blízká.
Naopak nepochopení je žít v bludu, že zasílání zpráv je jiný název pro volání metod s pozdní vazbou.
Tím bych to ze své strany uzavřel a doporučil Vám nějakou učebnici úplných základů objektově orientovaného programování, nejlépe od nějakého autora z prostředí otců-zakladatelů toho pojmu.
Doporučuji nastudovat myšlenky zmíněného Kaye, zatím jste ani nezačal.
-
odkazy?
V dokumentaci Cleanu jsem nenašel lautr nic a googlit se to nedá. U mercury jsem našel https://github.com/Mercury-Language/discussions/blob/master/parallelism_and_java/2013-10-23_thread-pools.txt což jsem si interpretoval jako 'par'. Nic lepšího jsem nenašel.
Haskellu zakážu forkIO a pár dalších, tak mám taky vyřešené vedlejší efekty. Co mi uchází?
Uchází ti, že v Haskellu může v jednu chvíli být neomezené množství světů najednou, kdežto v Cleanu pouze jeden.
Proto se tu furt dokola ptáme jestli clean umí vlákna. Pokud v Haskellu zakážeme forkIO tak je taky jenom jediný svět. Paralelismus jen přes spark pool umí Haskell taky.
To rozdvojení světa kvůli vláknům není vlastnost monádů. Je to tím, že existuje funkce forkIO, která ty monády obejde.
-
Jo ... můžu.
Ve zkratce. Uniqueness typing přidává do hry parametr času, není to moc vidět ale je to tak. V Haskellu parametr času není. Takže. Pokud máme objekt svět, pak v Haskellu nad tím jedním jedním objektem svět můžeme zavolat plno IO funkcí v různých vláknech, ty funkce vrátí svoje nové objekty svět a tak dál. Ve výsledku máme strašně moc objektů svět v jednu chvíli, a v různých vláknech. A tadá, race condition a nečistota.
tak má Clean vlákna nebo nemá? je nesmyslné takto porovnávat jazyk s vlákny a bez nich
máme li objekt world, pak operace IO bere tento objekt world, a vrací nový, ale ten starý není možné použit více, reference se po jednom použití stala neplatnou, protože kdyby ne, začalo by na objekt ukazovat více referencí. Tím je zajištěna čistota, protože poté i IO funkce se stejnými argumenty vrátí stejný výsledek opakovaně
tohle je prakticky popis IO monády, po provední vstupu/výstupu je starý "svět" již nedostupný a tudíž ho neleze znovu "použít"
Netuším
lež! A už sem ti dokonce i vysvětlil nohoře jak funguje IO monáda! Aspoň si to přečti a zamysli se nad tím. Právě že ten starý svět lze použít opakovaně. A ve více vláknech.
ale já vím jak funguje IO monáda, už pár let v Haskellu píšu
opravdu vám přijde vpořádku porovnávat situaci s jedním a více vlákny?
-
Samozřejmě, když v Haskellu zakážeme "nečistá" vlákna a ponecháme pouze čistý paralelismus pomocí par, pak dosáhneme stejného efektu jako poskytuje uniqueness typing. Nevýhoda je ale taková, že IO je potřeba dělat ve více vláknech (slabost uniqueness typing ...). A také se tak děje. Díky možnosti použití nečistých vláken ztratil Haskell čistotu. Projevila se slabost IO monády.
-
Řešením je reaktivita a nebo dosud nevyzkoušená komunikace pomocí lazy listů.
-
Samozřejmě, když v Haskellu zakážeme "nečistá" vlákna a ponecháme pouze čistý paralelismus pomocí par, pak dosáhneme stejného efektu jako poskytuje uniqueness typing. Nevýhoda je ale taková, že IO je potřeba dělat ve více vláknech (slabost uniqueness typing ...). A také se tak děje. Díky možnosti použití nečistých vláken ztratil Haskell čistotu. Projevila se slabost IO monády.
IO monáda a vlákna jsou na sobě nezávislé věci, jazyk může podporovat vlákna a nemusí využívat IO monádu
takže to vypadá, že jsme se dobrali k závěru, že IO monáda a uniqness typing jsou v jednovláknovém prostředí čumilovsky ekvivalentní (ref. tr.) nebo se pletu?
-
Samozřejmě, když v Haskellu zakážeme "nečistá" vlákna a ponecháme pouze čistý paralelismus pomocí par, pak dosáhneme stejného efektu jako poskytuje uniqueness typing. Nevýhoda je ale taková, že IO je potřeba dělat ve více vláknech (slabost uniqueness typing ...). A také se tak děje. Díky možnosti použití nečistých vláken ztratil Haskell čistotu. Projevila se slabost IO monády.
IO monáda a vlákna jsou na sobě nezávislé věci, jazyk může podporovat vlákna a nemusí využívat IO monádu
takže to vypadá, že jsme se dobrali k závěru, že IO monáda a uniqness typing jsou v jednovláknovém prostředí čumilovsky ekvivalentní (ref. tr.) nebo se pletu?
V jednovláknovém prostředí (ne, v jednovláknovém IO) jsou ekvivalentní. Uniqueness typing právě zabraňuje aby vedlejší efekty běželi ve více vláknech, což IO monáda nečiní. Takže ačkoli jsme se schodly, Haskell je nečistý.
-
Aby to nebylo pochopeno blbě, myslel jsem v jednovláknovém IO systému, když neděláme operace nad v čase proměnnými objekty, můžeme bez obav nasadit tolik vláken, kolik jich máme.
-
... nebo dosud nevyzkoušená komunikace pomocí lazy listů.
Ta nevyzkoušená komunikace pomocí lazy listů, co měla být Haskellu původně místo monádů? Nigel Perry ji ve své dizertaci rozebral celkem důkladně. Z představy toho datového typu se mi dělá kapku šoufl. A výsledkem by byl zase jednovláknový program seznam -> seznam. A kdyby se tam z praktických důvodů přidaly vlákna, jsou tam dvě nespojitelné funkce se stejnými problémy při synchronizaci jako mají monády.
-
Aby to nebylo pochopeno blbě, myslel jsem v jednovláknovém IO systému, když neděláme operace nad v čase proměnnými objekty, můžeme bez obav nasadit tolik vláken, kolik jich máme.
Haskell bez forkIO? Vždyť to tvrdíme celou dobu. Jednovláknové IO bude OK i pomocí monádů. V praxi je prostě vícevláknové IO potřeba, tak holt máme funkci pomocí které dokážeme monády obejít a ten svět si forknout.
-
Ve zkratce. Uniqueness typing přidává do hry parametr času, není to moc vidět ale je to tak. V Haskellu parametr času není. Takže. Pokud máme objekt svět, pak v Haskellu nad tím jedním jedním objektem svět můžeme zavolat plno IO funkcí v různých vláknech, ty funkce vrátí svoje nové objekty svět a tak dál. Ve výsledku máme strašně moc objektů svět v jednu chvíli, a v různých vláknech. A tadá, race condition a nečistota.
A uniqueness typing? Kdyby sis pořádně přečetl tu wiki, už by ti to bylo jasný. Uniqueness objekt může mít za svůj život pouze jednu jedinou referenci na sebe. Takže, máme li objekt world, pak operace IO bere tento objekt world, a vrací nový, ale ten starý není možné použit více, reference se po jednom použití stala neplatnou, protože kdyby ne, začalo by na objekt ukazovat více referencí. Tím je zajištěna čistota, protože poté i IO funkce se stejnými argumenty vrátí stejný výsledek opakovaně, představ si to jako stroj času :). Nevýhoda je, že IO je možno realizovat pouze na jednom vlákně, a proto je mnohem lepší použít reaktivitu.
Díky za příspěvek. Sice si trochu praštěnej s tím věčným osočováním jak to dotyční nečtou a nechápou, ale jsou tu i jiní, ti jsou za polopatické vysvětlení rádi.
-
Aby to nebylo pochopeno blbě, myslel jsem v jednovláknovém IO systému, když neděláme operace nad v čase proměnnými objekty, můžeme bez obav nasadit tolik vláken, kolik jich máme.
Haskell bez forkIO? Vždyť to tvrdíme celou dobu. Jednovláknové IO bude OK i pomocí monádů. V praxi je prostě vícevláknové IO potřeba, tak holt máme funkci pomocí které dokážeme monády obejít a ten svět si forknout.
No, a právě ten fakt, že IO monáda nezabraňuje forknutí světa činí IO monádu nečistou. Takže doufám, prosím bohy, že jsem konečně dovedl pár zatoulaných duší na správnou funkcionální cestu.
-
Ta nevyzkoušená komunikace pomocí lazy listů, co měla být Haskellu původně místo monádů?
Někdy se tomu říká Landin-stream IO - idea z roku 1965 - viz IO monad realized in 1965 (http://okmij.org/ftp/Computation/IO-monad-history.html). AFAIK používal to také jazyk Miranda.
-
Ve zkratce. Uniqueness typing přidává do hry parametr času, není to moc vidět ale je to tak. V Haskellu parametr času není. Takže. Pokud máme objekt svět, pak v Haskellu nad tím jedním jedním objektem svět můžeme zavolat plno IO funkcí v různých vláknech, ty funkce vrátí svoje nové objekty svět a tak dál. Ve výsledku máme strašně moc objektů svět v jednu chvíli, a v různých vláknech. A tadá, race condition a nečistota.
A uniqueness typing? Kdyby sis pořádně přečetl tu wiki, už by ti to bylo jasný. Uniqueness objekt může mít za svůj život pouze jednu jedinou referenci na sebe. Takže, máme li objekt world, pak operace IO bere tento objekt world, a vrací nový, ale ten starý není možné použit více, reference se po jednom použití stala neplatnou, protože kdyby ne, začalo by na objekt ukazovat více referencí. Tím je zajištěna čistota, protože poté i IO funkce se stejnými argumenty vrátí stejný výsledek opakovaně, představ si to jako stroj času :). Nevýhoda je, že IO je možno realizovat pouze na jednom vlákně, a proto je mnohem lepší použít reaktivitu.
Díky za příspěvek. Sice si trochu praštěnej s tím věčným osočováním jak to dotyční nečtou a nechápou, ale jsou tu i jiní, ti jsou za polopatické vysvětlení rádi.
Jo, asi sem praštěnej, ale ono to fakt tak je, plno lidí prostě rači ignoruje argumenty, než aby museli změnit chápaní dané věci. Je to ironie, ale cizinci jsou v tomhle strašní, ty fakt člověka ignorují a při zmínce impure Haskell tě naférovku pošlou do zadeke abys nevířil stojaté vody.
Jako tady lidi začali diskutovat a myslet trošku o tom, co sem říkal. Což je fajn. Ale už mi to ignorování trošku vlezlo na mozek mno.
-
No, a právě ten fakt, že IO monáda nezabraňuje forknutí světa činí IO monádu nečistou. Takže doufám, prosím bohy, že jsem konečně dovedl pár zatoulaných duší na správnou funkcionální cestu.
IO monáda forknutí světa zabraňuje. A proto, že je z praktických důvodů občas potřeba svět forknout, tak se přidaly funkce jako forkIO, které obejdou tu monádu a ten svět forknou.
Jestli se Clean začne víc používat, tak se tam stejným způsobem přidá funkce, co obejde ten unique svět a forkne ho. Proč? Protože je to občas potřeba.
-
Nigel Perry ji ve své dizertaci rozebral celkem důkladně.
Tu jsem neznal, díky. Také lze doporučit dizertaci Andrew Donalda Gordona Functional Programming and Input/Output (http://msr-waypoint.com/en-us/um/people/adg/Publications/fpio.pdf).
-
Ta nevyzkoušená komunikace pomocí lazy listů, co měla být Haskellu původně místo monádů?
Někdy se tomu říká Landin-stream IO - idea z roku 1965 - viz IO monad realized in 1965 (http://okmij.org/ftp/Computation/IO-monad-history.html). AFAIK používal to také jazyk Miranda.
wow, tak o tom sem nevěděl, že už to bylo nasazeno. Tendle nápad sem našel pod nějakým blogem s kritikou Haskellu, a toho nebožáka tam pak začal dav kamenovat, a vida, jeho nápad to originálně nebyl. Kamenovali špatnýho. Nezbývá než to uzavřít tak, že Haskell si prostě zvolil good enough cestu, žádné experimenty s čistotou, žádné optimisitic evaluation (až 30% speedup oproti lazy evaluation, což je WOW). Jediné co mi vadí je, že jeho autoři lžou a šíří dezinformaci. Jinak je to pěkný jazyk.
-
No, a právě ten fakt, že IO monáda nezabraňuje forknutí světa činí IO monádu nečistou. Takže doufám, prosím bohy, že jsem konečně dovedl pár zatoulaných duší na správnou funkcionální cestu.
IO monáda forknutí světa zabraňuje. A proto, že je z praktických důvodů občas potřeba svět forknout, tak se přidaly funkce jako forkIO, které obejdou tu monádu a ten svět forknou.
Jestli se Clean začne víc používat, tak se tam stejným způsobem přidá funkce, co obejde ten unique svět a forkne ho. Proč? Protože je to občas potřeba.
Pokud v Cleanu bude svět forknut, přestane být uniqueness typovaný a bude porušena jeho syntaktická integrita. Kdežto IO monáda je IO monádou i když je forknutá, žádné porušení systému se nekoná.
-
Samozřejmě, když v Haskellu zakážeme "nečistá" vlákna a ponecháme pouze čistý paralelismus pomocí par, pak dosáhneme stejného efektu jako poskytuje uniqueness typing. Nevýhoda je ale taková, že IO je potřeba dělat ve více vláknech (slabost uniqueness typing ...). A také se tak děje. Díky možnosti použití nečistých vláken ztratil Haskell čistotu. Projevila se slabost IO monády.
IO monáda a vlákna jsou na sobě nezávislé věci, jazyk může podporovat vlákna a nemusí využívat IO monádu
takže to vypadá, že jsme se dobrali k závěru, že IO monáda a uniqness typing jsou v jednovláknovém prostředí čumilovsky ekvivalentní (ref. tr.) nebo se pletu?
V jednovláknovém prostředí (ne, v jednovláknovém IO) jsou ekvivalentní. Uniqueness typing právě zabraňuje aby vedlejší efekty běželi ve více vláknech, což IO monáda nečiní. Takže ačkoli jsme se schodly, Haskell je nečistý.
já se asi začínám ztrácet, Haskell není čistý protože může mít vlákna?
-
Samozřejmě, když v Haskellu zakážeme "nečistá" vlákna a ponecháme pouze čistý paralelismus pomocí par, pak dosáhneme stejného efektu jako poskytuje uniqueness typing. Nevýhoda je ale taková, že IO je potřeba dělat ve více vláknech (slabost uniqueness typing ...). A také se tak děje. Díky možnosti použití nečistých vláken ztratil Haskell čistotu. Projevila se slabost IO monády.
IO monáda a vlákna jsou na sobě nezávislé věci, jazyk může podporovat vlákna a nemusí využívat IO monádu
takže to vypadá, že jsme se dobrali k závěru, že IO monáda a uniqness typing jsou v jednovláknovém prostředí čumilovsky ekvivalentní (ref. tr.) nebo se pletu?
V jednovláknovém prostředí (ne, v jednovláknovém IO) jsou ekvivalentní. Uniqueness typing právě zabraňuje aby vedlejší efekty běželi ve více vláknech, což IO monáda nečiní. Takže ačkoli jsme se schodly, Haskell je nečistý.
já se asi začínám ztrácet, Haskell není čistý protože může mít vlákna?
Protože může forknout IO monádu, respektive, že IO monáda něčemu takovému nezabraňuje jako v případě uniqueness typování.
-
a teď mě ještě napadlo jestli jde (pouze) s uniqness typing vynutit, že funkce neprovádí vstup/výstup, specificky v Haskellu s jeho typovým systémem to jde
-
Pokud v Cleanu bude svět forknut, přestane být uniqueness typovaný a bude porušena jeho syntaktická integrita. Kdežto IO monáda je IO monádou i když je forknutá, žádné porušení systému se nekoná.
Ne. Z pohledu typového systému to budou dva nezávislé unikátní objekty a zodpovědnost za synchronizaci přejde na programátora. Prostě se z praktických důvodů obejde omezení typovým systémem úplně stejně jako se obešlo u Haskellu.
-
No, a právě ten fakt, že IO monáda nezabraňuje forknutí světa činí IO monádu nečistou. Takže doufám, prosím bohy, že jsem konečně dovedl pár zatoulaných duší na správnou funkcionální cestu.
IO monáda forknutí světa zabraňuje. A proto, že je z praktických důvodů občas potřeba svět forknout, tak se přidaly funkce jako forkIO, které obejdou tu monádu a ten svět forknou.
Jestli se Clean začne víc používat, tak se tam stejným způsobem přidá funkce, co obejde ten unique svět a forkne ho. Proč? Protože je to občas potřeba.
Asi mi něco uniká, ale nedá mi, abych se nezeptal - není svět "forknutý" jaksi sám o sobě, respektive není hlavní problém v tom, že se po tom samém světě potulují různé entity, které svou přítomností ten společný svět mění? A pokud ano, není vlastně jedno, zda do světa, který je z důvodu přístupu ostatních entit nepredikovatelný a není možné si ho označkovat časem a očekávat po IO akci deterministický stav v čase t+1, přistupuje n entit nebo n+1, přičemž ta +1 je forknutá původní entita našeho programu napsaného v Haskellu?
-
Protože může forknout IO monádu, respektive, že IO monáda něčemu takovému nezabraňuje jako v případě uniqueness typování.
Tak znova. IO monáda forknutí brání. Proto tam kua taky je. To forknutí se dělá tak, že se ta monáda obejde. Je to tak těžké pochopit???
Jo, mohli bychom říct "tohle už není monáda, byla porušena integrita", ale k čemu by to bylo?
-
Pokud v Cleanu bude svět forknut, přestane být uniqueness typovaný a bude porušena jeho syntaktická integrita. Kdežto IO monáda je IO monádou i když je forknutá, žádné porušení systému se nekoná.
Ne. Z pohledu typového systému to budou dva nezávislé unikátní objekty a zodpovědnost za synchronizaci přejde na programátora. Prostě se z praktických důvodů obejde omezení typovým systémem úplně stejně jako se obešlo u Haskellu.
Ne a ne, přečti si pozorně dokumentaci Cleanu ohledně uniqueness typů, uniqueness typing je čisté právě tím, že zabraňuje ochcání, ničím jiným.
-
Protože může forknout IO monádu, respektive, že IO monáda něčemu takovému nezabraňuje jako v případě uniqueness typování.
Tak znova. IO monáda forknutí brání. Proto tam kua taky je. To forknutí se dělá tak, že se ta monáda obejde. Je to tak těžké pochopit???
Jo, mohli bychom říct "tohle už není monáda, byla porušena integrita", ale k čemu by to bylo?
Nebrání, forknutí IO neporuší typový systém Haskellu, uniqueness typing naopak forknutí brání, jinak by byl porušen typový systém.
-
Jo, mohli bychom říct "tohle už není monáda, byla porušena integrita", ale k čemu by to bylo?
Není důvod říkat, že to není monáda, když to monáda je (axiomy monád platí). Podobně tím není porušena referenční transparentnost.
-
Asi mi něco uniká, ale nedá mi, abych se nezeptal - není svět "forknutý" jaksi sám o sobě, respektive není hlavní problém v tom, že se po tom samém světě potulují různé entity, které svou přítomností ten společný svět mění? A pokud ano, není vlastně jedno, zda do světa, který je z důvodu přístupu ostatních entit nepredikovatelný a není možné si ho označkovat časem a očekávat po IO akci deterministický stav v čase t+1, přistupuje n entit nebo n+1, přičemž ta +1 je forknutá původní entita našeho programu napsaného v Haskellu?
Jde o seřazení operací které čtou a mění vnější svět. Samozřejmě že se dají synchronizovat jen změny světa, které udělal ten program. Samo že se ten svět mění i sám o sobě, ale nám jde o řazení našich operací.
Funkcionální jazyky neřeší vedlejší efekty, ale některé základní operace je samozřejmě mají (čtení znaku, souboru, ...), takže se musí nějak zařídit aby překladač ty operace nepřerovnal. Ale u všeho ostatního je to přerovnávání žádoucí.
U Unique typů se zavádí pomocný objekt Svět, který každá IO operace dostane jako parametr a vrátí ho upravený. Pokud typový systém zajistí že ten objekt existuje jenom jeden, tak se IO operace dají prodrátovat tím Světovým objektem jen za sebe.
IO Monád v haskellu dělá úplně to samé akorát ten Světový objekt je schovaný uvnitř a unikátnost nezajišťuje typový systém ale omezení operací, kterými se dají ty jednotlivé IO operace kombinovat.
Co tady čumil pořád opakuje je, že monády nejsou dost čisté, protože je z praktických důvodů možné obejít typový systém, svět forknout a spustit další vlákno. Kdyby se přidaly vlákna do Cleanu, tak tam bude muset být úplně stejný hack.
-
Takže. Můj poslední koment v tomhle vlákně. Je mi kuli nemoci blbě, takže nemám gule na to tady vést dál diskuzi, která jak vidím nic nepřinesla, vlastně si zase druhá strana jede to svoje. Což je škoda, zvláště jde li o něco tak krásného jako je funkcionální paradigma.
Haskell není čistý. Je zbytečné se vrtat ve vnitřnostech, akorát se zakecá to hlavní. Ve FP jazyce není třeba sdílenou paměť zamykat, nikdy se nemění. V Haskellu to neplatí. Ve FP jazyce vám v paměti nikdy nevznikne data race (a nejen v paměti, kdekoli, funkce nemají vedlejší efekty ...). V Haskellu musíme paměť zamykat aby se tak nestalo. Vše ukazuje že Haskell není čistý. Tečka.
Metody jak zajistit skutečně plnohodnotné IO se zachováním čistoty jsem už napsal. Není už nic více k řečení. Jen mne dost mrzí, že plno lidí, používajících FP nevidí jeho skutečnou krásu a sílu. Možná že toto zmatení, co vlastně FP je a není i způsobuje, že dosud nebylo více rozšířeno prostě proto, že plno nováčků vidí v logice nekonzistenci.
-
Nebrání, forknutí IO neporuší typový systém Haskellu, uniqueness typing naopak forknutí brání, jinak by byl porušen typový systém.
OKI, forkni mi monádu bez implementace na úrovni runtime (která samozřejmě typový systém obchází). Je to obdobné obejití typového systému, které by bylo potřeba pro spuštění plnotučného vlákna v Cleanu.
Ano, pokud zakážeme plnotučná vlákna, pak monády fungují úplně stejne jako unikátní typy. Hlavně proto, že IO monád je zabalený unikátní RealWorld, akorát je ta unikátnost zajištěná trochu jinak.
-
Haskell není čistý. Je zbytečné se vrtat ve vnitřnostech, akorát se zakecá to hlavní. Ve FP jazyce není třeba sdílenou paměť zamykat, nikdy se nemění. V Haskellu to neplatí. Ve FP jazyce vám v paměti nikdy nevznikne data race (a nejen v paměti, kdekoli, funkce nemají vedlejší efekty ...). V Haskellu musíme paměť zamykat aby se tak nestalo. Vše ukazuje že Haskell není čistý. Tečka.
Čistota jazyka ospravedlňuje používat tzv. substituční model, když zkoumáme kód v tom jazyce.
Naopak čistota neříká nic o tom, zda tam může nastat race-condition, zda lze přistupovat k paměti, která nepatří procesu, zda lze mít více vláken, zda může nastat dead-lock atd.
-
zdá se, že Clean má standardní knihovnu a zdá se, že ta má modul StdProcess, zmínka o funkci startIO, *World -> *World, víc to nestuduju, jestli se pletu tak mě někdo opravte
-
Jde o seřazení operací které čtou a mění vnější svět. Samozřejmě že se dají synchronizovat jen změny světa, které udělal ten program. Samo že se ten svět mění i sám o sobě, ale nám jde o řazení našich operací.
Funkcionální jazyky neřeší vedlejší efekty, ale některé základní operace je samozřejmě mají (čtení znaku, souboru, ...), takže se musí nějak zařídit aby překladač ty operace nepřerovnal. Ale u všeho ostatního je to přerovnávání žádoucí.
Dobrá, děkuju. Já jsem Haskellem trochu zasažený (hrál jsem si s ním na úrovni studia nějakých tutoriálů včetně nekonečných pokusů definovat co je monáda a spol., řešení úloh v Projektu Euler, jednodušších praktických prográmků, pročtení Real World Haskell i Learn You a Haskell, Typeclassopedie atd.). Dokonce jsem si chvilku hrál i s Concurrent Cleanem. Takže si troufám tvrdit, že v zásadě rozumím, o čem je řeč, ale nechápu spíš smysl sporu.
Jestliže do-notace definuje akci a v rámci IO monády (jak tady někdo psal, snad to moc nezkomolím) předpisuje akci pro interpret, který interaguje s vnějším světem, samozřejmě fork vlákna způsobí, že už nelze říci, která akce následuje po které. Nicméně se ptám, není porušením deterministického pořadí operací existence funkce typu random(), která samozřejmě existuje v Haskellu a jak koukám do knihoven Cleanu, je tam MersenneTwister a nevím, jak v Haskellu a Cleanu zabránit, aby v závislosti na vrácené hodnotě provedl jednu nebo druhou (třetí) operaci. Nebo samozřejmě to dělení může být na základě hodnoty načtené ze standardního vstupu, což je v zásadě totéž.
Jinými slovy mi přijde spor IO monády vs uniqueness typování poněkud malicherný, jelikož ve skutečnosti je problémem dichotomie funkcionální čistoty a reálného světa, kterou nelze žádným trikem přelstít, tudíž žádný prakticky použitelný jazyk nelze označit za čistě funkcionální, ale jsou jazyky, ve kterých lze napsat modul, který čistě funkcionální je, nicméně k tomu, aby dokázal alespoň vypsat výsledek výpočtu, potřebuje slupku, která udělá akci, jež vede k tomu výpisu. Haskell nabízí mechanismus pro vytvoření takové slupky, jenže ta slupka ožije až tím interpreterem, bez něj je to pořád jenom předpis a ne živá slupka.
No a teď zpátky k tomu forku - je samozřejmě poněkud nepříjemné, že nám z jednoho jabka vzniknou dvě a tudíž rozumování o výsledku bytí původně jednoho jabka ve světě je podstatně složitější, ale konečně složitější. Jenomže základní složitost není ve forkovitosti nebo IOMonádovitosti, ale ve slupkovitosti reálného programu.
Tudíž na jednu stranu chápu tvrzení, že Haskell není čistě funkcionální jazyk, na druhou stranu ale žádný prakticky použitelný jazyk není čistě funkcionální, tudíž striktní a úzká definice je dosti neužitečná.
-
malicherný
je malicherný, o tom snad nikdo nepochybuje, pro mě osobně to je intelektuální cvičení jehož předměte je ekvivalence IO monády v jednovláknovém prostředí a uniqness type
fork .. random()
já bych to zas tolik nepitval, mezi vláknem a procesem není tak velký rozdíl, program napsaný v Haskellu se dá spustit dvakrát paralelně, každé monády se vytvořit víc instancí (i když na IO je potřeba speciální magie) a random je akce v IO, které modifikuje její stav
-
Jestliže do-notace definuje akci a v rámci IO monády (jak tady někdo psal, snad to moc nezkomolím) předpisuje akci pro interpret, který interaguje s vnějším světem, samozřejmě fork vlákna způsobí, že už nelze říci, která akce následuje po které. Nicméně se ptám, není porušením deterministického pořadí operací existence funkce typu random(), která samozřejmě existuje v Haskellu a jak koukám do knihoven Cleanu, je tam MersenneTwister a nevím, jak v Haskellu a Cleanu zabránit, aby v závislosti na vrácené hodnotě provedl jednu nebo druhou (třetí) operaci. Nebo samozřejmě to dělení může být na základě hodnoty načtené ze standardního vstupu, což je v zásadě totéž.
MerseneTwister i ostatní pseudonáhodné generátory jsou deterministické. Třeba Haskellovská třída RandomGen popisuje objekt který obsahuje stav nějakého random generátoru. A funkce next vrací náhodné číslo a generátor s novým stavem. Vlastně se to dost podobá tomu RealWorld a taky to jde zabalit do monády :)
Pokud se MerseneTwister inicializuje stejně, tak bude vždycky vracet stejná čísla. Stejně tak deterministický program bude se stejným vstupem dělat to samé, takže ani ten standardní vstup determinismem nezahýbe.
Jinými slovy mi přijde spor IO monády vs uniqueness typování poněkud malicherný, jelikož ve skutečnosti je problémem dichotomie funkcionální čistoty a reálného světa, kterou nelze žádným trikem přelstít, tudíž žádný prakticky použitelný jazyk nelze označit za čistě funkcionální, ale jsou jazyky, ve kterých lze napsat modul, který čistě funkcionální je, nicméně k tomu, aby dokázal alespoň vypsat výsledek výpočtu, potřebuje slupku, která udělá akci, jež vede k tomu výpisu. Haskell nabízí mechanismus pro vytvoření takové slupky, jenže ta slupka ožije až tím interpreterem, bez něj je to pořád jenom předpis a ne živá slupka.
No a teď zpátky k tomu forku - je samozřejmě poněkud nepříjemné, že nám z jednoho jabka vzniknou dvě a tudíž rozumování o výsledku bytí původně jednoho jabka ve světě je podstatně složitější, ale konečně složitější. Jenomže základní složitost není ve forkovitosti nebo IOMonádovitosti, ale ve slupkovitosti reálného programu.
Tudíž na jednu stranu chápu tvrzení, že Haskell není čistě funkcionální jazyk, na druhou stranu ale žádný prakticky použitelný jazyk není čistě funkcionální, tudíž striktní a úzká definice je dosti neužitečná.
Ten spor vidím v ještě drobnější nuanci. Vypsání výsledku se dá udělat dokonale čistě. Jedno vlákno (z pohledu IO) bude čisté jak podle mně, tak podle čumila. Rozpor mezi mnou a čumilem byl vlastně v nuancích co je a co není čisté funkcionální programování. V cleanu nejsou plnotučná vlákna a díky tomu jdou seřadit operace tak, že program nemá uvnitř sebe šanci na nějaké race conditions a podobné věci. Není tam třeba synchronizovat paměť, ... Dá se využít více vláken, ale jen pro vyhodnocování výpočtů bez vedlejších efektů. Všechno s vedlejšími efekty je sesynchronizované jako by bylo v jednom vlákně. U Haskellu je to taky možné, pokud se povolí jen omezená paralelizace (např funkce "par") a nepovolí plnotučná vlákna (forkIO). A díky tomu, že se dá obejít typový systém a spustit další vlákna, není podle čumila Haskell čistě funkcionální.
Je to malicherný spor, to je jasné ;)
-
zdá se, že Clean má standardní knihovnu a zdá se, že ta má modul StdProcess, zmínka o funkci startIO, *World -> *World, víc to nestuduju, jestli se pletu tak mě někdo opravte
Byl by odkaz?
-
Tudíž na jednu stranu chápu tvrzení, že Haskell není čistě funkcionální jazyk, na druhou stranu ale žádný prakticky použitelný jazyk není čistě funkcionální, tudíž striktní a úzká definice je dosti neužitečná.
Pokud budete jako čistě funkcionální označovat jazyky, kde jsou všechny výrazy referenčně transparentní (výraz e je referenčně transparentní, pokud mohu v každém programu nahradit libovolné výskyty e hodnotou e a chování programu se nezmění), pak Haskell je čistě funkcionální (jak jsem již řekl, nepočítám do toho unsafePerformIO a spol.).
V čistě funkcionálních jazycích pak můžete používat substituční model - výrazy nahrazovat jejich hodnotami bez toho, aby se změnil význam programu. Třeba v OCamlu tohle nefunguje, tam se výraz print_endline "Hi" vyhodnotí na hodnotu () typu unit - když byste výraz print_endline "Hi" nahradil hodnotou (), přišel byste o vedlejší efekt, tj. změnil by se význam program. Zatímco v Haskellu výraz putStrLn "Hi" můžete chápat tak, že vrací hodnotu typu IO (), která pouze popisuje jaký vedlejší efekt se má udělat - kdybyste tuto hodnotu uměl přímo zkonstruovat, mohl byste jí nahradit výraz putStrLn "Hi" a význam programu by se nezměnil (nahradil byste výraz, který konstruuje popis, již zkonstruovaným popisem).
Kromě toho bývají Hindley–Milnerovské typové systémy jednodušší v čistých jazycích - v těch nečistých musíte omezit generalizaci (např. pomocí value restriction). Rovněž se některé optimalizace provádí snáze v čistých jazycích - proto je monadický kód v OCamlu, Scale a F# tak pomalý.
-
zdá se, že Clean má standardní knihovnu a zdá se, že ta má modul StdProcess, zmínka o funkci startIO, *World -> *World, víc to nestuduju, jestli se pletu tak mě někdo opravte
Byl by odkaz?
http://clean.cs.ru.nl/download/supported/ObjectIO.1.2/doc/tutorial.pdf
-
Ten spor vidím v ještě drobnější nuanci. Vypsání výsledku se dá udělat dokonale čistě. Jedno vlákno (z pohledu IO) bude čisté jak podle mně, tak podle čumila. Rozpor mezi mnou a čumilem byl vlastně v nuancích co je a co není čisté funkcionální programování. V cleanu nejsou plnotučná vlákna a díky tomu jdou seřadit operace tak, že program nemá uvnitř sebe šanci na nějaké race conditions a podobné věci. Není tam třeba synchronizovat paměť, ... Dá se využít více vláken, ale jen pro vyhodnocování výpočtů bez vedlejších efektů. Všechno s vedlejšími efekty je sesynchronizované jako by bylo v jednom vlákně. U Haskellu je to taky možné, pokud se povolí jen omezená paralelizace (např funkce "par") a nepovolí plnotučná vlákna (forkIO). A díky tomu, že se dá obejít typový systém a spustit další vlákna, není podle čumila Haskell čistě funkcionální.
Je to malicherný spor, to je jasné ;)
brání uniqness type implementaci něčeho jako forkIO? tj. v Clean asi forkWorld? přijde mi, že ne, ale nevim
-
brání uniqness type implementaci něčeho jako forkIO? tj. v Clean asi forkWorld? přijde mi, že ne, ale nevim
Podle čumila nejspíš jo :
Pokud v Cleanu bude svět forknut, přestane být uniqueness typovaný a bude porušena jeho syntaktická integrita. Kdežto IO monáda je IO monádou i když je forknutá, žádné porušení systému se nekoná.
Já osobně v tom vidím spíš slovíčkaření.
-
je malicherný, o tom snad nikdo nepochybuje, pro mě osobně to je intelektuální cvičení jehož předměte je ekvivalence IO monády v jednovláknovém prostředí a uniqness type
Já to vidím spíš tak, že čumil razantně nastoupil se silným tvrzením stylem "všichni jste pitomci, jenom já jsem letadlo a objevil jsem Ameriku". Škoda, že se nevyvaroval toho, že předem všechny považuje za neznalé pitomce, kterým zvěstuje evangelium. Všichni totiž nejspíš předem tušili, že to, co píše, není ve vícvláknovém programu možné, tak se ptali, jaký že to svatý grál přináší, a čumil velkolepě zvěstoval techniku, která ale teda bohužel funguje jenom v jednom vlákně. Čili nic, co by všichni ostatní nevěděli. A celé to čumilovo evangelium spočívá v tom, že Haskell není čistý, protože umožňuje IO ve víc vláknech. Což není žádný objevení Ameriky, to asi dojde každýmu... a je to prostě vědomý kompromis.
Čili je to asi tak, jako kdyby někdo nastoupil a tvrdil, že jediný by-design bezpečný OS je ten, který neumožňuje přistupovat k HW a síti. Což není nepravda, ale taky to není žádné zajímavé zjištění :)
-
je malicherný, o tom snad nikdo nepochybuje, pro mě osobně to je intelektuální cvičení jehož předměte je ekvivalence IO monády v jednovláknovém prostředí a uniqness type
Já to vidím spíš tak, že čumil razantně nastoupil se silným tvrzením stylem "všichni jste pitomci, jenom já jsem letadlo a objevil jsem Ameriku". Škoda, že se nevyvaroval toho, že předem všechny považuje za neznalé pitomce, kterým zvěstuje evangelium. Všichni totiž nejspíš předem tušili, že to, co píše, není ve vícvláknovém programu možné, tak se ptali, jaký že to svatý grál přináší, a čumil velkolepě zvěstoval techniku, která ale teda bohužel funguje jenom v jednom vlákně. Čili nic, co by všichni ostatní nevěděli. A celé to čumilovo evangelium spočívá v tom, že Haskell není čistý, protože umožňuje IO ve víc vláknech. Což není žádný objevení Ameriky, to asi dojde každýmu... a je to prostě vědomý kompromis.
Čili je to asi tak, jako kdyby někdo nastoupil a tvrdil, že jediný by-design bezpečný OS je ten, který neumožňuje přistupovat k HW a síti. Což není nepravda, ale taky to není žádné zajímavé zjištění :)
Teda, zvědavost mi prostě nedala, a kouknul jsem se, co se v tom nešťastném vlákénku děje. A co vidím? HE?? Mirek ze mě dělá debila. Takže jo, poruším to že se na to vlákno vyseru, sice je mi blbě, a zvěstovat teď pravdu fakt nebudu, ale musím se ohradit.
Já sem o nikom neřekl že je pitomec. Jo, klidně si všechno pročti. Nebo aspoň sem to neřekl člověku kterej argumentoval a nebo se o to pokoušel. Mno. A to že lidi moje argumenty nečtou a ani se nad nimi pořádně nezamýšlej je bohužel pravda. Sám si příkladem mého tvrzení.
Kdyby sis pořádně pročet (a taky si tomu věnoval pozornost), co jsme řešili od úplného začátku, zjistil by si, že tvůj aktuální komentář je prostě BULSHIT. Ano, jedna cesta jak řešit problémy s čistotou je umožnit IO pouze v jednom vlákně. Tadáááááá. První evangelium. Kdybys ale krom kopnutí si do mučedníka také četl, zjistil by si že jsem kázal o dalších dvou evangeliích. Přičemž obě dvě umožňují IO ve více vláknech (u toho druhého, respektive třetího, nevím, neměl jsem čest ho vyzkoušet, ale teoreticky vzato může runtime zpracovat požadavek z listu v kolika vláknech chce). Tak. Finito.
-
A co vidím? HE?? Mirek ze mě dělá debila.
To jsem neměl v úmyslu. Chtěl jsem jenom říct, že bombastičnost a arogantnost tvýho chování v mých očích neodpovídala (ne)závažnosti sdělení.
Já sem o nikom neřekl že je pitomec. Jo, klidně si všechno pročti.
To jsem právě udělal. Neměl jsem dneska čas debatu sledovat, takže jsem si to přečetl až teď celý v jednom kuse a udělalo to na mě dojem takový, jaký udělalo. A jestli chceš příklad příspěvku, tak třeba tenhle: http://forum.root.cz/index.php?topic=11417.msg134392#msg134392 Tohle prostě bylo zbytečný. Radek není žádnej pitomec a ví, o čem mluví, takovou reakci si imho nezasloužil. Škoda, že jsi téma nenastartoval raději s trochou skromnosti a pokory, mohli jsme si o tom dobře pokecat, mohlo to být zajímavý a nemuselo to skončit s tím, že práskneš dveřma a nazdar...
A to že lidi moje argumenty nečtou a ani se nad nimi pořádně nezamýšlej je bohužel pravda.
Není. V tom je právě ten problém, že jsi vyvolal mylný dojem, že přinášíš svatý grál, vyvolal jsi zájem a posluchače zklamal, protože jsi nepřinesl nic, co by (předpokládám) nevěděli od samého počátku.
Kdybys ale krom kopnutí si do mučedníka také četl, zjistil by si že jsem kázal o dalších dvou evangeliích. Přičemž obě dvě umožňují IO ve více vláknech (u toho druhého, respektive třetího, nevím, neměl jsem čest ho vyzkoušet, ale teoreticky vzato může runtime zpracovat požadavek z listu v kolika vláknech chce). Tak. Finito.
No o tom třetím (listy) zaznělo, že to tak v Haskellu bylo a upustilo se od toho. Čili nic nového.
S reaktivností je pak problém v tom, že to je dost buzzword a musel bys ukázat konkrétní příklad, co a jak to podle tebe řeší. Já třeba úplně nechápu, jak bys pomocí reaktivnosti řešil ten race condition (resp. deadlock), který jsi od začátku vykřikoval, že nutně chceš mít vyřešenej. V Erlangu se čistě reaktivní procesy používají běžně a deadlocky to nijak neřeší, spíš naopak. Pořád na ně musí programátor myslet, protože prostě cykly v posílání zpráv za tebe žádný překladač magicky nevyřeší.
No a kdyby ses do toho celýho nepustil tak zhurta a se svatým zápalem, mohli jsme o tom pokecat, jaký máš zkušenosti. Což teď půjde těžko a to je škoda, protože každej pokec o FP v češtině potěší...
-
dík za analýzu, až do teď se ty osobní útoky dařilo ignorovat
-
Mimochodem, docela mě zaujalo, jak tady kdosi zmínil, že v Cleanu (?) se explicitně pracuje s časem. To by mě docela zajímalo, jestli někdo nevíte o jazyku/knihovně, kde by čas byl fakt vyloženě explicitní - něco jako třeba v temporálních logikách nebo v logikách možných světů. To by mohl být docela hezký nástroj pro IO, kdyby se to vzalo za správný konec...
Nemáte k tomu někdo nějaký tip/zkušenost/poznatek?
-
Mimochodem, docela mě zaujalo, jak tady kdosi zmínil, že v Cleanu (?) se explicitně pracuje s časem. To by mě docela zajímalo, jestli někdo nevíte o jazyku/knihovně, kde by čas byl fakt vyloženě explicitní - něco jako třeba v temporálních logikách nebo v logikách možných světů. To by mohl být docela hezký nástroj pro IO, kdyby se to vzalo za správný konec...
Nemáte k tomu někdo nějaký tip/zkušenost/poznatek?
zmiňoval to čumil a myslím, že šlo spíš o seřazení akcí než přímo o čas
v Haskellu se s kombinací forkIO/delay/timeout/STM/mplus dají dělat docela zajímavé věci v časové oblasti
-
v Haskellu se s kombinací forkIO/delay/timeout/STM/mplus dají dělat docela zajímavé věci v časové oblasti
Mě šlo spíš o to, jestli někdo máte zkušenost s něčím, kde čas figuruje explicitně jako parametr. Nějakým způsobem by se pak asi dal řešit i ten problém IO ve víc vláknech, třeba by se ten parametr nějak atomicky inkrementoval a IO akce se tím řadily, nevím, plácám ;)
Matně si vzpomínám, že jsem jednou četl nějaký text, kde se tuším řešil nějaký popis konfigurace počítačů pomocí logiky nebo něco takovýho a tam právě se pracovalo s tím, že konfigurace v čase t je nějaká a pomocí nějaké přechodové funkce pak v t+1 nějaká jiná... Bohužel detaily už si nepamatuju, ani mě teď nenapadá, jak bych ten text našel.
-
tam právě se pracovalo s tím, že konfigurace v čase t je nějaká a pomocí nějaké přechodové funkce pak v t+1 nějaká jiná...
Asi to není ono, ale synchronní jazyky (https://en.wikipedia.org/wiki/Synchronous_programming_language) pracují s diskrétním časem, v taktech. Například při deklaraci proměnné lze určit agregační funkci - hodnoty přiřazené různými vlákny ve stejném čase t se pak zagregují pomocí této funkce.
-
Asi to není ono, ale synchronní jazyky (https://en.wikipedia.org/wiki/Synchronous_programming_language) pracují s diskrétním časem, v taktech. Například při deklaraci proměnné lze určit agregační funkci - hodnoty přiřazené různými vlákny ve stejném čase t se pak zagregují pomocí této funkce.
Není to ono, ale tohle je rozhodně taky zajímavý a neznal jsem. Kouknu, dík.
-
Ha, tak už vím, kde jsem o tom četl: http://www.bloom-lang.net/ a k tomu paper: http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.html (jedná se o Datalog - zjednodušený Prolog, rozšířený o temporalitu)
Ne, že by to nějak výrazně přispívalo k debatě, jenom jsem chtěl zamachrovat, že umím googlovat a nejsem už úplně sklerotickej ;)
-
...
Ne, že by to nějak výrazně přispívalo k debatě, jenom jsem chtěl zamachrovat, že umím googlovat a nejsem už úplně sklerotickej ;)
NJN, takhle po ránu.
Vyzkoušíme si Tě odpoledne ...
;)
-
Takže, rozhodl jsem se napsat něco jako moje vyjádření k FP a Haskellu, a to pak budu různě v diskuzích tapetovat, jinak to nejde, protože vždy když přijdu bez něčeho takového, tak nedokážu udržet konzistenci argumentů, a protože mám nezdravou vlastnost snažit se akceptovat názory ostatních (ostatní to ale tak necítí, a spokojeně kecají i o tom, o čem mají omezený přehled), dopadne to nakonec tak že říkám píčoviny jako že třeba IO monáda je čistá v jednom vlákně. Hovno. Takže tak, napsal sem fakt román, a pište svoje názory či otázky až poté, co se nad problémem zamyslíte. Omlouvám se za útoky a vulgarity, a dokonce se omlouvám i za to co teď řeknu, ale nemůžu si pomoct, každý kdo si myslí že je možné něco jako forkWorld v Cleanu je debil který nepochopil ani první větu na wiki o UT ale už se cítí plně kompetentní o tom diskutovat a zpochybňovat názory někoho kdo nad touto problematikou přemýšlel dlouhé dni. Ta první věta je "In computing, a unique type guarantees that an object is used in a single-threaded way, with at most a single reference to it." Ano, forkWorld by udělal dvě reference a tím by bylo porušeno pravidlo UT (a objekt by byl použit v multi-threaded way). Achjo :( Fakt, je mi to líto, ale už sem alergický na hlupáky, kteří ačkoli o tom nic neví, snaží se z člověka udělat debila a jeho dobrý nápad zakopat tím, že ho zahrnou kopou hloupých argumentů, a nebožák se v tom ještě sám zaplete. Vysral bych se na osvětu, měl bych víc času a míň nervů, ale FP si to zaslouží.
No a teď k tomu mého dlouhatáááánskému cancu ...
Mé stanovisko k FP a Haskellu
Tento, řekněme blok textu se bude dělit na několik částí, přičemž použité principy se budu snažit vysvětlovat. Není horší diskuze, než s člověkem který ačkoli zná určitou metodu 2 hodiny, cítí se plně oprávněn dělat závěry.
1) Co to je FP
2) Co může přinést FP
3) Řešení IO v Haskellu
4) Stručné shrnutí dalších možných metod řešení IO ve FP jazycích
5) Základní myšlenka uniqueness typing
6) Základní myšlenka FRP (reaktivní FP)
7) Základní myšlenka lazy listů (landin stream IO)
1) FP je paradigma, které je inspirované matematickou teorií funkcí a celkově podobou a chováním matematických výrazů. Jak se chovají matematické funkce ? Nemají žádný vnitřní stav, jediný vstup mají skrz své argumenty a jediný jejich výstup je hodnota kořenového výrazu funkce. Matematická funkce se stejnými argumenty vrátí vždy stejný výsledek. Je jedno kolikrát ji vyhodnotíme a nebo kdy ji vyhodnotíme. Matematická funkce je absolutně deterministická. Jak dosáhnout těchto parametrů v programovacím jazice ? Napřed musíme všechna data zmrazit, žádný objekt nesmí být po vytvoření měnitelný, v matematice také nezměníme již jednou přiřazenou hodnotu argumentu. Tím dosáhneme, že nemůžeme pomocí datové mutace výsledek funkce poslat skrz vstupní argumenty. Jako další krok musíme zajistit, aby funkce za žádnou cenu neměnila globální stav světa či běhového prostředí. Žádná matematická funkce něco takového neumí. Ale kdyby uměla, bylo by to fakt ale fakt drsný, jen si to představte, napíšete matematickou funkce, a postupně jak ji řešíte tak se třeba postaví dům (a nebo třeba smahnete někoho bleskem). Cool, vysvětlil sem magii. Ale tak to v našem vesmíru nefunguje. Teď zase vážně. Funkce, které splňují podmínky matematické funkce se nazývají čisté funkce, a jazyk je FP (dnes pure FP ...) pouze za předpokladu že všechny jeho funkce jsou čisté funkce.
2) FP díky tomu že má mnoho, řekněme omezení nabízí něco jako výměnu. Jsou to jistoty. A když máme jistoty, můžeme plno věcí optimalizovat a silně zrychlit. Takže. Začnem pěkně odzačátku.
- FP jazyky díky tomu že mají velmi vysokou úroveň abstrakce silně zkracují délku kódu. Zhruba 5 až 10. Tím usnadňují čitelnost a udržovatelnost.
- FP jazyky díky své vyšší abstrakci umožňují velmi snadno řešit problémy, které by s nižší úrovní abstrakce byli trošku problém.
- Díky determinismu usnadňují přemýšlení nad funkcí programu, což vede k menšímu počtu chyb
- Možnost silné optimalizace GC. GC ve FP jazycích je právě díky poskytovaným jistotám mnohem rychlejší, než GC v jazicích s měnitelným stavem. Na druhou stranu, FP jazyk k funkci potřebuje GC, protože přímé operace s pamětí nejsou čisté. A neměnná data potřebují k efektivní funkci GC taktéž. U nižších paradigmat GC ale není podmínkou, takže je to výhoda sporná.
- Možnost nahradit výraz jeho hodnotou bez porušení funkce programu. Řečeno stručně, můžeme cachovat výsledky funkcí, a tím na úkor paměti zrychlit vykonávání programu. Geniální a jednoduché.
- Možnost využití nestriktních vyhodnocovacích modelů funkcí, které není možné implicitně a bezpečně aplikovat v jazycích s měnitelným stavem a přesně danou sekvencí vykonávaných operací.
| call by need - možnost využívání nekonečných datových struktur, šetření procesorového času (obvykle nikoli) a paměti
| call by future - možnost implicitního paralelního vyhodnocování argumentů funkce bez nutnosti zamykání paměti (paměť se nikdy nemění).
... a mnoho dalších
- Právě call by future je nejsilnější schopnost FP, protože je možné psát implicitně plně paralelní programy bez žádných složitých a těžkopádných caviků známých z paradigmat s měnitelným stavem (kód není třeba nijak zvláštně modifikovat, všechno prostě funguje "samo"). V dnešní době se ale o nic podobného žádné runtime nepokusilo a navíc nemáme žádnou FP architekturu. Není ale nutná, neříkám že runtime s touto schopností by bylo snadné vytvořit, ale je to možné (napřed by tady ale musel být SKUTEČNĚ pure FP jazyk ...). Proč je ale schopnost implicitního paralelismu v jiných paradigmatech zapovězená? Funkce mají vedlejší účinky, a tyto vedlejší účinky se často musí provést v nějaké sekvenci, rozhodně ne paralelně. A jako další důvod zde máme měnitelnost dat a nutnost zamykání pro zabránění souběhu. Dokud máme málo jader, zamykání nesežere více než je zisk výkonu přidaného jádra. Čím je ale jader více, tím horší je mezi nimi synchronizace a zisk za každé přidané jádro se snižuje, až nakonec od určitého počtu jader začneme výkon místo zvyšování snižovat. Dnešní silně paralelní systémy to řeší rozdělením paměti na bloky, ale je to takové polovičaté řešení které komplikuje programování a snižuje potencionální výkonovou výtěžnost systému. Díky neměnnosti paměti ve FP ale není třeba nic zamykat, a tak můžeme mít v systému kolik jader chceme, výkon se bude jen zvyšovat. Dále díky absenci vedlejších efektů funkcí ani nezávisí na pořadí jejich vykonání. Jak jsem řekl nazačátku, implicitní neomezený a automatický paralelismus je nejsilnější zbraní FP.
---
jak vidno, FP má opravdu velmi mnoho výhod, a nedodržení podmínek FP nás v jazycích pak stojí vysokou cenu. Všechny (nebo aspoň ty nejlepší) tyto výhody.
3) Haskell se rozhodl vyřešit problémy s IO svérázně pomocí monád. Monáda je interface, která umožňuje vyjádřit sekvenci operací v nějakém prostředí. Prostředí může být obyčejný list a nebo celí svět. Sama o sobě monáda není nečistá. Její sílou je právě zajištění sekvence operací v prostředí, což se pro IO perfektně hodí. V Haskellu IO monáda není a ani nikdy neměla být čistá. Autoři Haskellu na čistotu tak trošku zanevřeli, protože podle nich čistě funkcionální program je jako černá krabice, jediné co můžeme říct je to, že se zahřívá. IO Monáda nás nezbaví vedlejších efektů, IO monáda ty vedlejší efekty zavře do klece aby neunikly do zbytku čistého kódu. Nic jiného neumí. A ani nikdy umět neměla. IO monáda zezačátku sloužila pro prosté IO, pak se přidaly měnitelné reference, které musí být zamykané, pokud k nim přistupujeme z více vláken. S měnitelnými referencemi se objevil další problém. Funkce může svůj výsledek poslat skrz své vstupní argumenty (silné porušení FP). A co je nejhorší, Haskell nás k tomu i nutí, prototže pokud chceme provádět IO ve více vláknech, musíme nějak výsledky z těchto vláken dostat. No, a samozřejmě jak jinak, uděláme to pěkně imperativně skrz jejich vstup. Protože Haskell nemá žádný použitelný FP GUI knihovnu, jsme odkázání na porty různých imperativních knihoven postavených na callbackách, no a aby ty callbacky k něčemu byli, musíme opět použít menitelné reference. Dále není pravda, že IO monáda je v jednom vlákně čistá. Není, sice nevznikne data race a měnitelné reference nemusíme zamykat, ale právě ony měnitelné reference boří celé FP, protože již nejde očekávat stejný výsledek při stejném vstupu. A nakonec, jakákoli funkce která pomocí IO monády dělá vedlejší efekty rozhodně nemůže být nahrazena svou návratovou hodnotou. Proč? Protože výstup těchto funkcí může být takřka kdekoli, a nebo klidně skrz vstupní argumenty. A také se v závislosti vnějšího prostředí výstup funkce se stejnými argumenty mění. Uzavřít je to možno tak, že Haskell ani nikdy neměl být čistý, měl být prostě dostatečně dobrý a relativně snadno implementovatelný. Tu jeho vlastnost "dostatečně dobrý" je možno dokumentovat i v případě optimistic evaluation (něco jako lazy evaluation akorát na steroidech). Optimisitc evaluation dávalo oproti lazy evaluation zhruba 30% lepší výsledky. Nikdy se ale nedostalo dál než jen k experimentům. Pro Haskell to prostě byla zbytečná snaha, už tak byl dobrý, co si komplikovat práci. Je obtížné zjistit na internetu vyjádření k tomuto, jednou se mi ale podařilo na Haskell cafe najít vysvětlení že prostě je to moc komplikované (ve zkratce, jsme líný). Haskell je rozhodně moc hezký jazyk, ale autoři lžou. Není to pure FP jazyk, pouze jen FP jazyk (toto označení se bohužel vžilo pro všechny funkcionální jazyky s vyjímkami čistoty, a nejen pro ně, jsou idioti kteří jsou schopni říct že FP je i Python, či jakýkoli jazyk s funkcemi že ...).
4) Ony ale existují cesty na IO se zachováním čistoty. A nepochybně existuje mnoho dalších, neobjevených.
- Uniqueness typing
- Reactivity
- Lazy message streams (aka landin streams)
5) Základní myšlenka UT je ta, že na měnitelný objekt může ukazovat jen jedna jediná reference, ne více. Lze si to představit jako kdyby jsme spojili měnitelnou hodnotu s parametrem času. Takováto měnitelná hodnota může být jen v jednom vlákně, už z logiky věci, kdyby byla ve více vláknech, byla by porušena podmínka UT jedné reference. Z toho důvodu je něco na způsob forkWorld nemožné protože by to nedovolil typový systém (v Haskellu forkIO neporušuje pravidla monád, to jen rýpnutí). Co z toho plyne? Měnitelná hodnota se stane po jednom použití nepoužitelná, a aby jsme ji mohly použít, musí někde vzniknout nová reference na její verzy v čase t+1. Tím je zajištěno, že ačkoli funkce dělá vedlejší efekty, jsou svázané s časem, a protože se neumíme vrátit v čase zpět, nemůže se nečistota nikdy projevit (funkce dělající vedlejší efekty není nikdy zavolána vícekrát se stejnými parametry, nemůže). UT je spíš ochcání čistoty než její řešení. Její hlavní nevýhoda je IO jen v jednom vlákně, a to je nepochybně důvod, proč se s UT v budoucnu nikdy ve vetším jazyce nepotkáme.
6) Reaktivita. V dnešní době se jedná o nejlepší řešení. Čisté funkce usměrňují a transformují signály v uzlech grafu signálů. Vstupy a výstupy grafu signálu můžou běžet v oddělených vláknech a i samotné transformační uzly mohou běžet ve svých vláknech. Tak jako GC přesunulo management paměti na runtime místo na jazyk, tak reaktivita přesune IO z jazyka na runtime. Výsledek? Píšeme čistě funkcionální kód bez poskvrnky, o IO se stará sám systém, mi jen funkcionálně modifikujeme proudy signálů. A samozřejmě, mohou se plně projevit všechny FP výhody. Pro bližší studium navrhuji kouknout se na jazyky na návrh EL obvodů a nebo na jazyk Elm.
7) Poslední metoda funguje trošku podobně jako reaktivita. Vstupní funkce bere jako argument nekonečný list zpráv a vrací nekonečný list odpovědí, o IO se opět stará runtime, nikoly jazyk. IO může běžet ve více vláknech, podle chuti runtimu, a mi pracujeme jen s čistým kódem který může využít všech FP výhod.
-
Boha jeho. Že se v cleanu nedá výstup funkce předávat skrz vstupní argumenty vykládej někomu, kdo nečetl manuál. Uvědomuješ si, co s tvým ideálem o čistotě udělají RW soubory? ::)
Kdyby sis raději přečetl ty dizertace, co tu padly. Ale to ty ne. Ty budeš raději tapetovat svou směs trivialit a omylů.
-
Boha jeho. Že se v cleanu nedá výstup funkce předávat skrz vstupní argumenty vykládej někomu, kdo nečetl manuál. Uvědomuješ si, co s tvým ideálem o čistotě udělají RW soubory? ::)
Kdyby sis raději přečetl ty dizertace, co tu padly. Ale to ty ne. Ty budeš raději tapetovat svou směs trivialit a omylů.
Achjo :(
Ne nedá (a kdyby dalo, super UT by se tím pádem stalo lží taktéž, nic víc nic míň). A proč nedá?
somefun :: *World -> ()
No, takováhle funkce nám v Cleanu spolehlivě zařízne IO skrz World. Po zavolání této funkce už prostě World nemáme, na World verze t nemůže ukazovat více referencí, aby funkce byla použitelná, musí vypadat takto
somefun :: *World -> *World
Přičemž vrátí novou referenci na World t+1 kterou dále můžeme použít. Z toho vyplývá, výstup nejde poslat skrz vstup, respektive jde, ale nejde se k němu dostat, takže je to k ničemu.
A pokud sis laskavě přečetl Clean dokumentaci, pak víš že každá funkce pracující *World taktéž *World vrací, obvykle v tuple pokud vrací ještě něco jinýho. Jenže ty sis jí včera přečetl stejně kvalitně jako wiki o UT, takže nejde očekávat bohužel nic jiného mno. :(
RW soubory neudělají nic ... opravdu vůbec nic.
Směs trivialit a omylů říkáš. :( To si nezaslouží reakci
-
A co takhle funkce
read :: String *World -> Int *World
write :: String Int *World -> *World
Nejsem si jistý, jestli je ta syntaxe úplně ok, ale princip je doufám jasný. Jestli má mutable proměnná speciální typ IORef, nebo obyč String je úplně putna. Implementovat to pomocí souborů předpokládám zvládneš.
-
A takové pěkné úteý to mohlo bejt ...
-
import Control.Monad.State
f = evalState g 0
where g = do
a <- get
put 1
b <- get
return (a, b)
main = print f
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
dále k tématu: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
-
každý kdo si myslí že je možné něco jako forkWorld v Cleanu je debil který nepochopil ani první větu na wiki o UT
Ne, ty jsi nepochopil ten argument:
1. Haskell záměrně umožňuje jakousi (dle tebe) prasárnu, aby umožnil něco, co by jinak nebylo možné
2. Kdyby Clean chtěl umožnit to samé, pak by musel umožnit tu samou prasárnu (a tím by opustil tu čistotu, v tom máš pravdu)
3. Kdyby[/b] chtěl být Haskell čistý, tak by tu prasárnu neumožnil.
Všimni si prosím, že "pak by musel umožnit" není totéž jako "umožňuje".
(netvrdím, že to takhle je, na to znám Haskell málo, jenom reprodukuju ten argument, jak jsem ho pochopil já)
-
Jsem čumila pochopil tak, že dotyčná prasárna v Haskellu udělat jde, protože to stačí naimplementovat, zatímco v Cleanu to nejde, protože by se musel komplet přepracovat idea typového systému.
-
Jsem čumila pochopil tak, že dotyčná prasárna v Haskellu udělat jde, protože to stačí naimplementovat, zatímco v Cleanu to nejde, protože by se musel komplet přepracovat idea typového systému.
Ale v cleanu to taky stačí jenom naimplementovat. To, že to zatím naimplementované není, umožňuje čumilovi snít o tom, že tomu typový systém nějak brání. Brání tomu úplně stejně jako monády, tzn. pro spuštění vlákna je třeba funkce, která ten typový systém obejde.
On si čumil pořád nějak odmítá připustit že unique typing dělá to samé jako monády. Zavírá kód s vedlejšími efekty do klece, aby se udržel na jednom místě a zbytek programu zůstal čistý. I ty mutable proměnné tam jdou bez problémů implementovat současnými prostředky (žádné FFI ani změny runtime, čistě v cleanu) bez nějakého brutálního znásilnění nevinného jazyka.
-
Jsem čumila pochopil tak, že dotyčná prasárna v Haskellu udělat jde, protože to stačí naimplementovat, zatímco v Cleanu to nejde, protože by se musel komplet přepracovat idea typového systému.
Typový systém je jen sada odvozovacích pravidel. Do UT lze forkWorld přidat jednoduše - do jazyka stačí přidat konstantu forkWorld a typový systém rozšířit o pravidlo (axiom), které jí přiřadí typ.
Mj. úplně stejným způsobem se do jazyka a jeho typového systému přidávají například čísla, n-tice (produkty) nebo sumy. Stejným způsobem lze do jazyka přidat i funkci coerce pro přetypování. Viz například Type systems for programming languages, kapitola 3.6 Simple extensions (http://gallium.inria.fr/~remy/mpri/2013/cours.pdf#32).
-
každý kdo si myslí že je možné něco jako forkWorld v Cleanu je debil který nepochopil ani první větu na wiki o UT
Ne, ty jsi nepochopil ten argument:
1. Haskell záměrně umožňuje jakousi (dle tebe) prasárnu, aby umožnil něco, co by jinak nebylo možné
2. Kdyby Clean chtěl umožnit to samé, pak by musel umožnit tu samou prasárnu (a tím by opustil tu čistotu, v tom máš pravdu)
3. Kdyby[/b] chtěl být Haskell čistý, tak by tu prasárnu neumožnil.
Všimni si prosím, že "pak by musel umožnit" není totéž jako "umožňuje".
(netvrdím, že to takhle je, na to znám Haskell málo, jenom reprodukuju ten argument, jak jsem ho pochopil já)
Clean tu prasárnu nemůže provést proboha ... forkIO neporušuje typový systém a ani pravidla monád. Něco jako forkWorl v UT ale porušuje pravidla UT a tím pádem i typový systém. Proboha, musím to psát furt dokolečka jen proto že ňákýho tydýta napadlo, že ačkoli se o tom dozvěděl před 2 dni poprvé, už to plně chápe a může rozdávat moudrost ...
ALE mimochodem, je bezvadné že už z toho konečně některým vyplynulo že Haskell rozhodně není pure a lže.
-
Jsem čumila pochopil tak, že dotyčná prasárna v Haskellu udělat jde, protože to stačí naimplementovat, zatímco v Cleanu to nejde, protože by se musel komplet přepracovat idea typového systému.
HALELUJA :) ostrůvek porozumnění
-
Takže já už to teda nějak za sebe uzavřu. Už doopravdy. Jednou jeden slavný člověk řekl velmi moudrou větu.
"Není horší hádky, než hádky s idiotem, napřed vás stáhne na svou úroveň a poté umlátí zkušenostmi"
Je to strašně nadčasové mpudro, a já už začínám cítít, že kdybych se tady dál snažil stát v cestě té ignoranci, postupně bych byl na tu úroveň stáhnut a umlácen zkušenostmi. Takže už v zájmu sebe to tady musím opustit.
Snad si někteří anonymní čtenáři přečetly co sem napsal, nemusí tomu hned věřit, stačí, když si o metodách o kterých jsem mluvil něco sami nastudují, zamyslí se jak fungují, a třeba si znovu projdou CO vlastně to FP originálně je. Dřív nebo později mi dají za pravdu. Ale ne hned, člověk nad tím musí přemýšlet, a musí nad tím přemýšlet tak, že hledá proč to funguje a ne proč to nefunguje jako tady pánové JSH a Radek.
Dřív jsem si myslel že Haskell je skutečně čistý, ale to IO mi stejně připadalo takové, divné. Nechápal jsem, jak to může být čisté. Až poté, co jsem napsal větší projekt v Haskellu, a měl sem tu možnost se do jazyka a jeho systému trochu hlouběji ponořit, začal jsem tušit, že on ani čistý není. Vlastně mne nakoply měnitelné reference, ty mi přišli divný, ale ještě divnější bylo, že sem se jim prostě nemohl vyhnout.
Tak to je vše, někdy přístě v jiném vlákně, se třeba pude bavit o tom, proč to funguje, a ne proč to nefunguje ...
-
... forkIO neporušuje typový systém a ani pravidla monád. ...
Zeptám se znova. Jak bys rozdvojil RealWorld bez podpory, která umožňuje ty monády rozbalit?
Kdybys chtěl v cleanu plnotučná vlákna, tak prostě runtime bude muset podporovat funkci
forkIO :: (*World -> *World) *World -> *World
Ta funkce udělá naprosto to samé, co forkIO v Haskellu :
1) Vybalí World z krabice. Je úplně jedno jestli je tu krabici dělá IO Monád, nebo unique typ
2) Zkopíruje World a oba dva zase zabalí
3) Spustí další vlákno s jednou kopií světa.
Unikátní typy tomu brání úplně stejně jako monády : Je nutné je s podporou jazyka/runtime obejít úplně stejně jako ty monády
A připomínám ti, že s pomocí souborů se dá bez jakékoliv podpory na úrovni runtime implementovat IORef. Takže unikátní typy brání zabraňují vytváření mutable proměnných úplně stejně jako monády. Nijak
-
A ještě zdůrazním proč
2) Zkopíruje World a oba dva zase zabalí
nemusí porušovat unikátní typování.
Vzhledem k tomu, že World je "fake" objekt jen k řazení vedlejších efektů, není třeba ho kopírovat. Stačí vytvořit nový, který je úplně nezávislý na tom prvním. Je to úplně stejné jako když z jednoho unique souboru načtu jméno druhého a vytvořím druhý nezávislý unikátní soubor. Na oba dva můžu mít jenom jednu jedinou referenci a z pohledu typového systému jsou úplně nezávislé.
Stejně tak forkIO v Haskellu vytváří druhý úplně nezávislý IO objekt a z pohledu jazyka ty dva nemají nic společného.
-
Něco jako forkWorl v UT ale porušuje pravidla UT a tím pádem i typový systém.
forkWorld pravidla UT neporušuje. Lze maximálně říci, že UT neobsahuje pravidla pro otypování forkWorld, ale stejně tak neobsahuje pravidla pro otypování 1 + 1 nebo jiných výrazů, které se v jazyce Clean používají. Důvodem je, že UT nezná konstanty 1, forkWorld a +. Jak jsem naznačil, UT si můžete o tyto konstanty rozšířit.
Může se stát, že takové rozšíření nebude konzervativní (https://en.wikipedia.org/wiki/Conservative_extension).
Ta první věta je "In computing, a unique type guarantees that an object is used in a single-threaded way, with at most a single reference to it." Ano, forkWorld by udělal dvě reference a tím by bylo porušeno pravidlo UT (a objekt by byl použit v multi-threaded way).
Věta "In computing, a unique type guarantees that an object is used in a single-threaded way, with at most a single reference to it.", není pravidlo UT, je to vlastnost pravidel UT. Přidání nových pravidel může tuto vlastnost zneplatnit, ale to neznamená, že by nová pravidla byla v rozporu s těmi starými.
-
http://www.rarous.net/weblog/448-deset-duvodu-proc-nepouzivat-funkcionalni-jazyky.aspx (http://www.rarous.net/weblog/448-deset-duvodu-proc-nepouzivat-funkcionalni-jazyky.aspx)
;)
-
http://www.rarous.net/weblog/448-deset-duvodu-proc-nepouzivat-funkcionalni-jazyky.aspx (http://www.rarous.net/weblog/448-deset-duvodu-proc-nepouzivat-funkcionalni-jazyky.aspx)
;)
To je aspoň vhled odborníka. Ten má tydlencty typový systémy a referenční transparenty v malíčku.
-
Jsem čumila pochopil tak, že dotyčná prasárna v Haskellu udělat jde, protože to stačí naimplementovat, zatímco v Cleanu to nejde, protože by se musel komplet přepracovat idea typového systému.
Typový systém je jen sada odvozovacích pravidel. Do UT lze forkWorld přidat jednoduše - do jazyka stačí přidat konstantu forkWorld a typový systém rozšířit o pravidlo (axiom), které jí přiřadí typ.
A bude to potom ještě Uniqueness typing? Já v tomto samozřejmě nejsem nějak extra odborník, ale jak jsem to pochopil: když do jazyka s monádama naimplementuješ forkIO, který forkne tu monádu, tak jsi sice použil hrubou sílu, ale monády jsou spokojený. Neporušil jsi žádný jejich axiom. Zatímco když do jazyka s Uniqueness typing naimplementuješ něco jako forkWorld, tak jsi taky dosáhl svého, taky použil hrubou sílu, ale už to nebude Uniqueness typing, protože jsi porušil pravidlo ohledně jediné instance.
Jako ve výsledku vlastně jde jen o to, že když něco nazveš nějak, tak od toho taky něco očekáváš. A když od jazyka, který o sobě tvrdí, že je pure funkcional, a on pak ve skutečnosti není, tak to naštve. Když by se řeklo, že Haskell je "pure funkcional s výhradou", tak by byl třeba čumil spokojenej.
-
pure funkcional
jak to definujete? :)
-
pure funkcional
jak to definujete? :)
Na čumilově definici se neshodneme?
1) FP je paradigma, které je inspirované matematickou teorií funkcí a celkově podobou a chováním matematických výrazů. Jak se chovají matematické funkce ? Nemají žádný vnitřní stav, jediný vstup mají skrz své argumenty a jediný jejich výstup je hodnota kořenového výrazu funkce. Matematická funkce se stejnými argumenty vrátí vždy stejný výsledek. Je jedno kolikrát ji vyhodnotíme a nebo kdy ji vyhodnotíme. Matematická funkce je absolutně deterministická. Jak dosáhnout těchto parametrů v programovacím jazice ? Napřed musíme všechna data zmrazit, žádný objekt nesmí být po vytvoření měnitelný, v matematice také nezměníme již jednou přiřazenou hodnotu argumentu. Tím dosáhneme, že nemůžeme pomocí datové mutace výsledek funkce poslat skrz vstupní argumenty. Jako další krok musíme zajistit, aby funkce za žádnou cenu neměnila globální stav světa či běhového prostředí. Žádná matematická funkce něco takového neumí. Ale kdyby uměla, bylo by to fakt ale fakt drsný, jen si to představte, napíšete matematickou funkce, a postupně jak ji řešíte tak se třeba postaví dům (a nebo třeba smahnete někoho bleskem). Cool, vysvětlil sem magii. Ale tak to v našem vesmíru nefunguje. Teď zase vážně. Funkce, které splňují podmínky matematické funkce se nazývají čisté funkce, a jazyk je FP (dnes pure FP ...) pouze za předpokladu že všechny jeho funkce jsou čisté funkce.
Plus případně explicitně vyjádření o referenční transparentnosti (to kdyby někdo přišel s nějakou haluzí, i když mě to z té definice vyplývá).
-
No, a ještě jsem tam měl zvýraznit to s těma side efektama.
-
Zatímco když do jazyka s Uniqueness typing naimplementuješ něco jako forkWorld, tak jsi taky dosáhl svého, taky použil hrubou sílu, ale už to nebude Uniqueness typing, protože jsi porušil pravidlo ohledně jediné instance.
Když bychom vzali nějakou konkrétní formulaci UT (například z dizertace Dana Harringtona A type system for destructive updates in declarative programming languages (http://web.archive.org/web/*/http://pages.cpsc.ucalgary.ca/~danaha/uniqueness-types.ps)), tak tam nejspíš žádné pravidlo ohledně jediné instance nebude. Budou tam jen pravidla, která říkají, že za určitých předpokladů lze přiřadit výrazům určitý typ. Naopak tam nebudou pravidla, která by říkala, že určitým výrazům nejde přiřadit určitý typ. Když tam tedy přidám axiom, že výraz forkWorld má určitý typ, tak se nemohu dostat do sporu se stávajícími pravidly - ze stávajících pravidel nejde odvodit negace přidaného axiomu.
Tvrzení "In computing, a unique type guarantees that an object is used in a single-threaded way, with at most a single reference to it." slouží jako motivace pro pravidla v UT.
A bude to potom ještě Uniqueness typing?
Myslím, že by se tomu říkalo UT, i kdyby tam přibyla funkce coerce, která provede libovolné přetypování (pomocí ní můžete napsat i forkWorld).
Viz třeba dokumentace jazyka Idris (http://docs.idris-lang.org/en/latest/reference/uniqueness-types.html).
Jako ve výsledku vlastně jde jen o to, že když něco nazveš nějak, tak od toho taky něco očekáváš. A když od jazyka, který o sobě tvrdí, že je pure funkcional, a on pak ve skutečnosti není, tak to naštve. Když by se řeklo, že Haskell je "pure funkcional s výhradou", tak by byl třeba čumil spokojenej.
Ale Safe Haskell s IO monádou bez věcí jako unsafePerformIO, unsafeCoerce atd., je čistě funkcionální - definici splňuje bez výhrad (všechny výrazy tam jsou referenčně transparentní). Rovněž tam funguje substituční model, když zkoumáte chování programů.
-
Na čumilově definici se neshodneme?
Ta v Haskellu platí i s IO monádou.
-
tak já po příspěvku RM už jenom doplním, že z toho obrovského čumilova příspěvku je zřejmé, že nepochopil jak monáda funguje (to o měnitelných referencích) a proto asi to nedorozumění
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Jako ve výsledku vlastně jde jen o to, že když něco nazveš nějak, tak od toho taky něco očekáváš. A když od jazyka, který o sobě tvrdí, že je pure funkcional, a on pak ve skutečnosti není, tak to naštve. Když by se řeklo, že Haskell je "pure funkcional s výhradou", tak by byl třeba čumil spokojenej.
Ale Safe Haskell s IO monádou bez věcí jako unsafePerformIO, unsafeCoerce atd., je čistě funkcionální - definici splňuje bez výhrad (všechny výrazy tam jsou referenčně transparentní). Rovněž tam funguje substituční model, když zkoumáte chování programů.
Ale v normálním Haskellu tedy funkce jako unsafePerformIO, unsafeCoerce atd. jsou, takže takovej Haskell není čistě funkcionální. Obvykle se bavíme o Haskellu, ne o Safe Haskellu (to abyste mě neařkli ze slovíčkaření). I na wikině je, že Safe Haskell je čistě funkcionální. Na několika místech. Takže si dovedu představit jak se při čtení něčeho takového musí čumil vztekat.
Bohužel o tom, jak funguje Uniqueness typing vím kulové, takže nemohu argumentovat. Chápal jsem to tak, že z nějaké, jakési, definice se musí jednat vždy o jednu instanci (představil jsem si to jak UID, u kterého by mě taky naštvalo, když by nějaká aplikace měla stejné jako já.) Pokud to tak není, tak budu jen rád, když se tu o tom rozkecáte podobně jako čumil :-)
-
... ale už to nebude Uniqueness typing, protože jsi porušil pravidlo ohledně jediné instance.
Uniqueness typing nijak neomezuje počet instancí. Jen na každou z nich může být jenom jedna reference. Těch instancí světů může být klidně milion a uniqueness typing ani nepípne, pokud bude mít každá jen po jedné referenci na ni.
Uniqueness typing ani nemůže omezovat počet instancí, protože by se nedal využít u věcí jako jsou třeba soubory.
-
unsafePerformIO
pro pořádek, Safe Haskell není jiný jazyk/dialekt, je to nastavení překladače
a s unsafePerformIO Haskell čistý není, ale GHC chce být užitečný a tak je občas pragmatický (což je protipól nábožensko fundamentalisktického)
-
Pragmatickou stránku věci chápu.
-
... ale už to nebude Uniqueness typing, protože jsi porušil pravidlo ohledně jediné instance.
Uniqueness typing nijak neomezuje počet instancí. Jen na každou z nich může být jenom jedna reference. Těch instancí světů může být klidně milion a uniqueness typing ani nepípne, pokud bude mít každá jen po jedné referenci na ni.
Uniqueness typing ani nemůže omezovat počet instancí, protože by se nedal využít u věcí jako jsou třeba soubory.
Takže otevřu soubor, získám instanci na ten soubor (definovanou jako UT), takže ten soubor už nemůžu otevřít jinde a získat druhou instanci na ten souboru?
-
Ale v normálním Haskellu tedy funkce jako unsafePerformIO, unsafeCoerce atd. jsou, takže takovej Haskell není čistě funkcionální. Obvykle se bavíme o Haskellu, ne o Safe Haskellu (to abyste mě neařkli ze slovíčkaření). I na wikině je, že Safe Haskell je čistě funkcionální. Na několika místech. Takže si dovedu představit jak se při čtení něčeho takového musí čumil vztekat.
Takhle prostě dopadá konflikt teoretické čistoty a praktických požadavků. Reálný svět je jedna obrovská smrdutá hromada stavu. Kromě unsafe funkcí má Haskell i FFI (může volat C funkce) a díky tomu se mu dá vnutit cokoliv. FFI má i clean. Navíc nedokumentované, takže je to dvojnásobná past. Díky FFI bychom i o cleanu mohli tvrdit, že při fanatické aplikaci definic není čistě funkcionální. Akorát by to k ničemu nebylo.
Bohužel o tom, jak funguje Uniqueness typing vím kulové, takže nemohu argumentovat. Chápal jsem to tak, že z nějaké, jakési, definice se musí jednat vždy o jednu instanci (představil jsem si to jak UID, u kterého by mě taky naštvalo, když by nějaká aplikace měla stejné jako já.) Pokud to tak není, tak budu jen rád, když se tu o tom rozkecáte podobně jako čumil :-)
Jestli znáš C++, tak uniqueness typing trochu odpovídá move semantice. Na každý objekt je jedna jediná reference. Objekty se tak dají třeba modifikovat, protože se žádné jiné referenci nezmění pod rukama.
Takže otevřu soubor, získám instanci na ten soubor (definovanou jako UT), takže ten soubor už nemůžu otevřít jinde a získat druhou instanci na ten souboru?
Jestli se soubor nedá otevřít jinde musí hlídat OS. Protože musí hlídat i jiné procesy. Je to o něčem jiném.
Pokud soubor otevřu pro čtení, tak nemusí být unikátní. Můžu si handle zkopírovat a ten soubor předat 10 různým funkcím. Na všech místech dostanu stejná data.
Pokud otevřu soubor pro čtení i zápis, tak dostanu unikátní referenci na něj. Teď ten soubor nemůžu číst z více míst, protože zápis z jednoho místa by ten soubor změnil a na druhém míste bych dostal jiná data. Další funkci ho můžu předat až mi ho ta první zase vrátí. Samozřejmě se to dá obejít, třeba ten soubor otevřít vícekrát. Takže to chrání hlavně před chybami.
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
Ale v normálním Haskellu tedy funkce jako unsafePerformIO, unsafeCoerce atd. jsou, takže takovej Haskell není čistě funkcionální. Obvykle se bavíme o Haskellu, ne o Safe Haskellu (to abyste mě neařkli ze slovíčkaření).
Ty funkce jsou rozšíření GHC Haskellu, v Haskell 2010 Language Report o nich není ani zmínka - je tam však FFI a některá chování tam nejsou definována - v těchto případech Haskell nemusí být čistě funkcionální.
Chápal jsem to tak, že z nějaké, jakési, definice se musí jednat vždy o jednu instanci
Obecně typový systém nic (takového) negarantuje. Například, říká-li typový systém, že výraz má typ int, neznamená to, že když výraz vyhodnotíte, tak dostanete celé číslo - klidně můžete dostat řetězec nebo instanci třídy Pes nebo něco úplně jiného.
Celé číslo byste dostal, pokud by byl typový systém korektní (sound) vzhledem k nějaké (operační) sémantice.
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
já bych řekl, že třeba systémové volání v IO se zaseknout může
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
Jinak řečeno, čistě funkcionální není interpretr, který interpretuje hodnotu typu IO (), jenž vrátila funkce main. Naštěstí ten interpretr není součástí vašeho programu nebo jazyka - nemáte k němu přístup (až na unsafePerformIO apod.).
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
já bych řekl, že třeba systémové volání v IO se zaseknout může
Ano, ale váš kód žádné systémové volání neprovádí. Ten pouze vrací popis, jaké systémové volání se má provést (popis typu IO a).
-
Takže otevřu soubor, získám instanci na ten soubor (definovanou jako UT), takže ten soubor už nemůžu otevřít jinde a získat druhou instanci na ten souboru?
Jestli se soubor nedá otevřít jinde musí hlídat OS. Protože musí hlídat i jiné procesy. Je to o něčem jiném.
Pokud soubor otevřu pro čtení, tak nemusí být unikátní. Můžu si handle zkopírovat a ten soubor předat 10 různým funkcím. Na všech místech dostanu stejná data.
Pokud otevřu soubor pro čtení i zápis, tak dostanu unikátní referenci na něj. Teď ten soubor nemůžu číst z více míst, protože zápis z jednoho místa by ten soubor změnil a na druhém míste bych dostal jiná data. Další funkci ho můžu předat až mi ho ta první zase vrátí. Samozřejmě se to dá obejít, třeba ten soubor otevřít vícekrát. Takže to chrání hlavně před chybami.
Tak samozřejmě se bavíme o otevření na více místech v rámci toho programu. A předpokládáme, že do toho souboru jiný program nezasahuje. Je to ideální případ pro ilustraci.
Takže otevřu soubor, získám instanci na ten soubor (definovanou jako UT), takže ten soubor už nemůžu otevřít jinde a získat druhou instanci na ten souboru?
Pokud otevřu soubor pro čtení i zápis, tak dostanu unikátní referenci na něj. Teď ten soubor nemůžu číst z více míst, protože zápis z jednoho místa by ten soubor změnil a na druhém míste bych dostal jiná data. Další funkci ho můžu předat až mi ho ta první zase vrátí. Samozřejmě se to dá obejít, třeba ten soubor otevřít vícekrát. Takže to chrání hlavně před chybami.
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.)
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
já bych řekl, že třeba systémové volání v IO se zaseknout může
Ano, ale váš kód žádné systémové volání neprovádí. Ten pouze vrací popis, jaké systémové volání se má provést (popis typu IO a).
Takže tu máme jazyk Haskell, který je čistě funkcionální, a pak interprety/kompilátory, který ty jazyky neimplementují přesně? Takže když napíši program v Haskellu vracející IO se systémovým voláním, které vede k souběhu, tak neexistuje implementace kompilátoru, která by si s tím poradila. Správně?
-
Obecně typový systém nic (takového) negarantuje. Například, říká-li typový systém, že výraz má typ int, neznamená to, že když výraz vyhodnotíte, tak dostanete celé číslo - klidně můžete dostat řetězec nebo instanci třídy Pes nebo něco úplně jiného.
Celé číslo byste dostal, pokud by byl typový systém korektní (sound) vzhledem k nějaké (operační) sémantice.
Typový systém mi zabrání přeložit program, který používá funkci, jenž podle signatury má vracet int, ale nevrací. Záleží na tom, zda to nazveš korektností, nebo garancí? Program z toho nevytvořím, takže mi to přijde garantovaný ažaž.
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
já bych řekl, že třeba systémové volání v IO se zaseknout může
Ano, ale váš kód žádné systémové volání neprovádí. Ten pouze vrací popis, jaké systémové volání se má provést (popis typu IO a).
Takže když napíši program v Haskellu vracející IO se systémovým voláním, které vede k souběhu, tak neexistuje implementace kompilátoru, která by si s tím poradila.
Váš program v Haskellu, vaše funkce main vrací popis toho, jaká systémová volání se mají provést. Funkce main čistá, jelikož vrací pokaždé stejný popis.
Spuštění toho popisu není součástí vašeho programu - ať to spuštění popisu vede k čemukoliv, tak to nemá vliv na to, zda je jazyk čistě funkcionální. Programy v čistě funkcionálních jazycích tak mohou dělat vše co programy v jiných jazycích - ručně alokovat paměť, přistupovat na určité adresy v paměti, způsobovat race conditions.
-
Mě tam zase zaujalo to vztekání se ohledně Race Condition. Je fakt, že když je něco funkcionální podle té čumilově definice, tak k souběhu nesmí dojít. Představuji si naivní situaci, kdy jedna funkce v sobě volá jinou funkci, která čeká na vrácení hodnoty předchozí funkce. Každopádně, když použiji dvě funkce (forknuté ze stejného IO), které čtou ze stejného souboru (zamčeného), tak se prostě zaseknou bez ohledu na to, že jsou monadické. (Trošku vařím z vody, k forkIO jsem se ještě nedostal.) A vzhledem k tomu, že se zaseknou, tak je porušena funkcionálnost.
Ty funkce se nezaseknou - normálně doběhnou a vrátí hodnotu typu IO a pro nějaké a. Vrácené hodnoty se pak skombinují pomocí >>= z IO monády a vznikne jedna obří hodnota IO () - tu vrátí funkce main - žádný vedlejší efekt se neprovede, nic se nezasekne.
já bych řekl, že třeba systémové volání v IO se zaseknout může
Ano, ale váš kód žádné systémové volání neprovádí. Ten pouze vrací popis, jaké systémové volání se má provést (popis typu IO a).
a co tohle:
import Control.Concurrent.MVar
main = do
v <- newMVar 0
takeMVar v
print 1
takeMVar v
print 2
-
Takže když napíši program v Haskellu vracející IO se systémovým voláním, které vede k souběhu, tak neexistuje implementace kompilátoru, která by si s tím poradila.
Váš program v Haskellu, vaše funkce main vrací popis toho, jaká systémová volání se mají provést. Funkce main čistá, jelikož vrací pokaždé stejný popis.
Spuštění toho popisu není součástí vašeho programu - ať to spuštění popisu vede k čemukoliv, tak to nemá vliv na to, zda je jazyk čistě funkcionální. Programy v čistě funkcionálních jazycích tak mohou dělat vše co programy v jiných jazycích - ručně alokovat paměť, přistupovat na určité adresy v paměti, způsobovat race conditions.
Tomu, že IOMonáda je popis já, věřím, že dostatečně, rozumím.
Vás bych ale poprosil zda byste odpověděl na otázku: Když napíšu v Haskellu jakožto pure funkcionálním jazyku program který je schopen vést k souběhu, tak mám či nemám k dispozici kompilátor, který je schopen jej přeložit tak, aby k souběhu nedošlo (páč souběh odporuje definici funkcionality).
-
Spuštění toho popisu není součástí vašeho programu - ať to spuštění popisu vede k čemukoliv, tak to nemá vliv na to, zda je jazyk čistě funkcionální. Programy v čistě funkcionálních jazycích tak mohou dělat vše co programy v jiných jazycích - ručně alokovat paměť, přistupovat na určité adresy v paměti, způsobovat race conditions.
To se kardinálně pletete, funkcionální program může nanejvýš vyblít skript pro nefunkcionální část a tím to hasne. Pak musí nastoupit nefunkcionální programátor a tento musí napsat nefunkcionální interpret toho nefunkcionálního skriptu. Tvrzení že když může funkcionální program vyblít skript tak může všechno, je od základu pomýlené.
-
Obecně typový systém nic (takového) negarantuje. Například, říká-li typový systém, že výraz má typ int, neznamená to, že když výraz vyhodnotíte, tak dostanete celé číslo - klidně můžete dostat řetězec nebo instanci třídy Pes nebo něco úplně jiného.
Celé číslo byste dostal, pokud by byl typový systém korektní (sound) vzhledem k nějaké (operační) sémantice.
Typový systém mi zabrání přeložit program, který používá funkci, jenž podle signatury má vracet int, ale nevrací.
Obecně nic takového neplatí - typový systém a operační sémantika jsou dvě nezávislé věci. Například jazyky Dart a Typescript mají záměrně nekorektní typové systémy.
Záleží na tom, zda to nazveš korektností, nebo garancí? Program z toho nevytvořím, takže mi to přijde garantovaný ažaž.
Korektností (angl. soundness) myslím přesně definovanou věc (http://www.cs.cornell.edu/courses/cs6110/2013sp/lectures/lec27-sp13.pdf). Součástí důkazu korektnosti bývá věta "preservation", která říká, že se typ termu během vyhodnocování nemění (což mj. ne ve všech jazycích platí).
-
Vás bych ale poprosil zda byste odpověděl na otázku: Když napíšu v Haskellu jakožto pure funkcionálním jazyku program který je schopen vést k souběhu, tak mám či nemám k dispozici kompilátor, který je schopen jej přeložit tak, aby k souběhu nedošlo (páč souběh odporuje definici funkcionality).
Nevím, zda takový kompilátor existuje.
Pokud neexistuje, ničemu to nevadí - nic to nemění na věci, že všechny výrazy v Haskellu (až na unsafePerformIO apod.) jsou referenčně transparentní.
-
Obecně nic takového neplatí - typový systém a operační sémantika jsou dvě nezávislé věci. Například jazyky Dart a Typescript mají záměrně nekorektní typové systémy.
Můžeš tohle prosím rozvést nebo dát nějaký odkaz? Zajímalo by mě, jak přesně nekorektní a jaký je ten záměr (k čemu to má vést).
-
Vás bych ale poprosil zda byste odpověděl na otázku: Když napíšu v Haskellu jakožto pure funkcionálním jazyku program který je schopen vést k souběhu, tak mám či nemám k dispozici kompilátor, který je schopen jej přeložit tak, aby k souběhu nedošlo (páč souběh odporuje definici funkcionality).
Nevím, zda takový kompilátor existuje.
Pokud neexistuje, ničemu to nevadí - nic to nemění na věci, že všechny výrazy v Haskellu (až na unsafePerformIO apod.) jsou referenčně transparentní.
Pokud to nevíte vy, tak to pro mě znamená, že neexistuje :-)
Všechny výrazy v Haskellu odpovídají ideálům FP, ale když se v praxi na ně nemůžete spolehnout, tak bohužel platí, že:
jak vidno, FP má opravdu velmi mnoho výhod, a nedodržení podmínek FP nás v jazycích pak stojí vysokou cenu.
Všechny výrazy v Haskellu jsou referenčně transparentní... ale čistě teoreticky, dokavad to nechcete použít.
Pak se tedy obávám, že vyskakování čumila je více než dost pochopitelné, když věnujete čas, úsilí a peníze do něčeho, co vám slibuje něco co nakonec nedodrží. Asi bych vyskakoval taky, když bych si Haskell nezamiloval kůli něčemu jinému.
-
Obecně nic takového neplatí - typový systém a operační sémantika jsou dvě nezávislé věci. Například jazyky Dart a Typescript mají záměrně nekorektní typové systémy.
Můžeš tohle prosím rozvést nebo dát nějaký odkaz? Zajímalo by mě, jak přesně nekorektní a jaký je ten záměr (k čemu to má vést).
Kvůli pohodlí programátorů - viz Unsound and Incomplete (http://www.brandonbloom.name/blog/2014/01/08/unsound-and-incomplete/). Nebo Why Dart Types Are Optional and Unsound (https://www.dartlang.org/articles/why-dart-types/) nebo oficiální manuál TypeScriptu (http://www.typescriptlang.org/Handbook#type-compatibility).
-
Všechny výrazy v Haskellu odpovídají ideálům FP, ale když se v praxi na ně nemůžete spolehnout, tak bohužel platí, že:
jak vidno, FP má opravdu velmi mnoho výhod, a nedodržení podmínek FP nás v jazycích pak stojí vysokou cenu.
Všechny výrazy v Haskellu jsou referenčně transparentní... ale čistě teoreticky, dokavad to nechcete použít.
Ale ty výrazy jsou referenčně transparentní i prakticky a GHC toho využívá při optimalizacích - například Stream Fusion, nebo obecně uživatelem definovaná přepisovací pravidla - kdyby ten jazyk nebyl čistý, tohle by bylo mnohem obtížnější.
-
odpovídají ideálům FP, ale když se v praxi na ně nemůžete spolehnout, tak bohužel platí, že:
Pokud hledáte typový systém, který zabrání vzniku race conditions, tak můžete zkusit Rust (jeho bezpečný fragment) nebo Mezzo (http://protz.github.io/mezzo/).
Ani jeden z nich není čistě funkcionální.
-
Kvůli pohodlí programátorů - viz Unsound and Incomplete (http://www.brandonbloom.name/blog/2014/01/08/unsound-and-incomplete/). Nebo Why Dart Types Are Optional and Unsound (https://www.dartlang.org/articles/why-dart-types/) nebo oficiální manuál TypeScriptu (http://www.typescriptlang.org/Handbook#type-compatibility).
Díky. Už je dost pozdní hodina, takže mi možná něco ušlo, ale ten první link mi to teda moc neosvětlil a v tom textu o Dartu je jenom příklad s downcastem, kterej je jasnej, ale nevím
1. jestli je to jediná věc, u které je ne-korektní, nebo je jich víc (jasně že jedna věc stačí k tomu aby byl nekorektní jako takový, ale to teď nemyslím)
2. V čem je to zjednodušení pro programátora? Že může použít downcast bez toho, aby to udělal explicitně? To mi moc jako výhoda ani nepřijde :)
-
odpovídají ideálům FP, ale když se v praxi na ně nemůžete spolehnout, tak bohužel platí, že:
Pokud hledáte typový systém, který zabrání vzniku race conditions, tak můžete zkusit Rust (jeho bezpečný fragment) nebo Mezzo (http://protz.github.io/mezzo/).
Ani jeden z nich není čistě funkcionální.
Chápu to tak, že zabránění race conditions je pro FP podmínka nutná, nikoliv však dostačující.
A, bohužel, z tohoto vlákna si zatím odnáším dojem, že zrovna Haskell čistě funkcionální není. Minimálně prakticky. Dokonce jakoby funkcionální paradigma byl ideál, kterého se všemožné jazyky pokoušejí dosáhnout, a když už jsou na devadesáti procentech, tak se označují za pure :-)
O Rust už jsem zakopl, na Mezzo se podívám, díky za tip. A vůbec, díky za příspěvky.
-
Dokonce jakoby funkcionální paradigma byl ideál, kterého se všemožné jazyky pokoušejí dosáhnout, a když už jsou na devadesáti procentech, tak se označují za pure :-)
Ty, teďka čistě přízemně a prakticky: a není to jedno? Zajímá tě primárně, jestli jazyk splňuje nějaká víceméně umělá akademická kritéria, nebo jestli se v něm dobře píše?
Mě třeba fakt nadchl Elixir a přitom z těch akademických "kritérií funkcionálnosti" nesplňuje skoro nic, někdo ho do FP vůbec neřadí, někdo ho klidně zařadí do "opravdové OOP" (kvůli posílání zpráv), někdo ho dá do "concurrent programming"... A není to ve finále úplně jedno? Stejně v praxi tě víc zajímají věci jako pattern matching, nároky na paměť, rychlost, snadnost paralelizace... ne?
Popravdě řečeno mi ten čumilův přístup přijde poněkud (až značně ;) ) autistickej :)
-
1. jestli je to jediná věc, u které je ne-korektní, nebo je jich víc (jasně že jedna věc stačí k tomu aby byl nekorektní jako takový, ale to teď nemyslím)
V Dartu to jsou ještě kovariantní generika - typový systém povolí kontravarianci, ale za běhu to spadne. Například
abstract class Zvire { void jez(); }
class Pes extends Zvire { void jez() { print("Pes"); } }
abstract class Krmic<A> { void nakrm(A a); }
class ZvireKrmic extends Krmic<Zvire> {
void nakrm(Zvire z) { z.jez(); }
}
void f(Krmic<Pes> k, Pes p) {
k.nakrm(p);
}
void start() {
f(new ZvireKrmic(), new Pes());
}
projde typovou kontrolou, ale za běhu vyhodí
Breaking on exception: type 'ZvireKrmic' is not a subtype of type 'Krmic<Pes>' of 'k'.
TypeScript má například špatně varianci u polí (měly by být invariantní, neměnná pole mohou být kovariantní, pole pouze pro zápis mohou být kontravariantní, v TypeScriptu jsou však bivariantní) a argumentů funkcí (měly by být kontravariantní).
2. V čem je to zjednodušení pro programátora? Že může použít downcast bez toho, aby to udělal explicitně? To mi moc jako výhoda ani nepřijde :)
Údajně je to intuitivnější.
-
Dokonce jakoby funkcionální paradigma byl ideál, kterého se všemožné jazyky pokoušejí dosáhnout, a když už jsou na devadesáti procentech, tak se označují za pure :-)
Ty, teďka čistě přízemně a prakticky: a není to jedno?
Samozřejmě že v praxi je to jedno. Samozřejmě že to není jedno v okamžiku, kdy zvažuješ, že se ten jazyk naučíš.
Popravdě řečeno mi ten čumilův přístup přijde poněkud (až značně ;) ) autistickej :)
Může bejt, ale dozvěděl jsem se spousta zajímavejch věcí.
-
Chápu to tak, že zabránění race conditions je pro FP podmínka nutná, nikoliv však dostačující.
Ne, není to vůbec potřeba, FP může mít race conditions.
Nutná a postačující podmínka je, že můžete používat substituční model na všechny výrazy - tj. každý výraz můžete nahradit jeho hodnotou aniž by se chování programu změnilo. Důsledkem je, že výrazy, jenž mají stejnou hodnotu, jsou záměnné (tohle například v Javě neplatí).
-
V Dartu to jsou ještě kovariantní generika - typový systém povolí kontravarianci, ale za běhu to spadne. Například
Díky moc za příklad, ale z OOP už jsem dost vypadl a sotva už držím víčka, projdu zítra :)
Údajně je to intuitivnější.
Pro webaře odchované JavaScriptem určitě ;)
Samozřejmě že to není jedno v okamžiku, kdy zvažuješ, že se ten jazyk naučíš.
Záleží, jaký máš cíl. Ten Erlang je třeba z hlediska čistě akademickýho celkem nezajímavej hnůj, ale z hlediska použití je to prostě paráda :) Je na tom dost poznat, že chtěli vyvinout jazyk pro dobré řešení konkrétních průmyslových úloh - a dělali na tom lidi, kteří fakt nejsou hloupí a (až na drobnosti) zvolili parádní kompromisy, který do sebe zapadají jak zadek na nočník :)
Může bejt, ale dozvěděl jsem se spousta zajímavejch věcí.
Každopádně si zaslouží dík za rozproudění hezké a neobvykle poučné debaty, o tom žádná :)
-
každý výraz můžete nahradit jeho hodnotou aniž by se chování programu změnilo
Ať nad tím dumám jak dumám, vychází mi z toho, že to právě race conditions vylučuje.
-
Chápu to tak, že zabránění race conditions je pro FP podmínka nutná, nikoliv však dostačující.
Ne, není to vůbec potřeba, FP může mít race conditions.
Přesněji při interpretaci popisu, co vyleze z čistého funkcionálního programu, mohou vznikat race conditions.
Samotný funkcionální program je skutečně matematická funkce, která nemá race conditions, neboť pouze vrací popis.
-
každý výraz můžete nahradit jeho hodnotou aniž by se chování programu změnilo
Ať nad tím dumám jak dumám, vychází mi z toho, že to právě race conditions vylučuje.
Opravil jsem se.
-
Samozřejmě že to není jedno v okamžiku, kdy zvažuješ, že se ten jazyk naučíš.
Záleží, jaký máš cíl. Ten Erlang je třeba z hlediska čistě akademickýho celkem nezajímavej hnůj, ale z hlediska použití je to prostě paráda :) Je na tom dost poznat, že chtěli vyvinout jazyk pro dobré řešení konkrétních průmyslových úloh - a dělali na tom lidi, kteří fakt nejsou hloupí a (až na drobnosti) zvolili parádní kompromisy, který do sebe zapadají jak zadek na nočník :)
Spíše jsem to myslel tak, že když řekneš: "Erlang je z akademického hlediska hnůj, ale z praktického hlediska paráda" tak k tomu tak budu přistupovat a nebudu zklamanej. Když se řekne, že "Erlang je snadnej, programuje se sním skoro samo a umí vařit kafe" tak budu mírně naprdlej, když po letech usilovného studia a třech nedodělaných aplikacích si musím kafe furt vařit sám.
-
Ať nad tím dumám jak dumám, vychází mi z toho, že to právě race conditions vylučuje.
Když dumáš "uvnitř" toho jazyka, tak vylučuje - ale zároveň nemůže nijak ovlivnit okolní svět, což není moc praktické :)
čumil to napsal docela dobře: matematická funkce ti dům nepostaví. (udělá to za ni nějaký "runtime")
-
Přesněji při interpretaci popisu, co vyleze z čistého funkcionálního programu, mohou vznikat race conditions.
Tohle dilema už jsme snad uzavřeli ;-)
-
Ať nad tím dumám jak dumám, vychází mi z toho, že to právě race conditions vylučuje.
Když dumáš "uvnitř" toho jazyka, tak vylučuje - ale zároveň nemůže nijak ovlivnit okolní svět, což není moc praktické :)
čumil to napsal docela dobře: matematická funkce ti dům nepostaví. (udělá to za ni nějaký "runtime")
Jenže čumila jsem pochopil tak, že i když to runtime dělá side effecty, tak nemusí ustupovat až tak daleko, že bude umožňovat i race conditions (přeci jenom, side-efect je užitečný, zatímco race conditions vůbec). Proto uváděl další implementace řešení FP: uniqueness typing (rozumím jakžtakž), FRP (nerozumím vůbec).
-
Jenže čumila jsem pochopil tak, že i když to runtime dělá side effecty, tak nemusí ustupovat až tak daleko, že bude umožňovat i race conditions (přeci jenom, side-efect je užitečný, zatímco race conditions vůbec).
No to je zajímavá otázka - jestli by šlo nějak zabezpečit, aby jazyk předal runtimu zaručeně jenom takové instrukce, které by zaručeně nevedly k race condition. Pokud myslíš RC obecně (síť, paměť, disk, čekání na zprávy...) tak si to fakt neumím představit :) Třeba chytré hlavy už něco vymyslely, akorát to zas bude mít nějaké jiné neblahé praktické důsledky ;)
Proto uváděl další implementace řešení FP: uniqueness typing (rozumím jakžtakž), FRP (nerozumím vůbec).
To první jsme asi už proprali dostatečně... A to druhý nevím nevím, že by se pomocí toho dalo vyhnout jakejmkoli cyklům _obecně_? Neuvěřím dokud neuvidím ;)
-
Jenže čumila jsem pochopil tak, že i když to runtime dělá side effecty, tak nemusí ustupovat až tak daleko, že bude umožňovat i race conditions (přeci jenom, side-efect je užitečný, zatímco race conditions vůbec).
No to je zajímavá otázka - jestli by šlo nějak zabezpečit, aby jazyk předal runtimu zaručeně jenom takové instrukce, které by zaručeně nevedly k race condition. Pokud myslíš RC obecně (síť, paměť, disk, čekání na zprávy...) tak si to fakt neumím představit :)
Já mám na mysli jen ty v rámci daného runtime/programu. Obecný si taky nedovedu představit.
Třeba chytré hlavy už něco vymyslely, akorát to zas bude mít nějaké jiné neblahé praktické důsledky ;)
Vo tom nepochybuji.
-
Ať nad tím dumám jak dumám, vychází mi z toho, že to právě race conditions vylučuje.
Když dumáš "uvnitř" toho jazyka, tak vylučuje - ale zároveň nemůže nijak ovlivnit okolní svět, což není moc praktické :)
čumil to napsal docela dobře: matematická funkce ti dům nepostaví. (udělá to za ni nějaký "runtime")
Jenže čumila jsem pochopil tak, že i když to runtime dělá side effecty, tak nemusí ustupovat až tak daleko, že bude umožňovat i race conditions (přeci jenom, side-efect je užitečný, zatímco race conditions vůbec). Proto uváděl další implementace řešení FP: uniqueness typing (rozumím jakžtakž), FRP (nerozumím vůbec).
No to je podle mě právě ta potíž, UT podle Čumila neumožňuje chybu souběhu jenom proto, že znemožňuje výpočet ve více vláknech, FRP se problému vyhýbá tím, že řízení výpočtu ponechává vně referenčně transparentních funkcí a Haskell to momentálně řeší IO monádou, která vrací popis akce, která má imperativní charakter a operuje ve světě, který běží v čase, je stavový a vládne v něm konkurence, do které vstupuje náš program v jednom nebo více vláknech. To je svět, který je úplně mimo dosah matematické funkce a proto snaha "smířit" reálný svět se světem čistě funkcionálním tak, jak by se Ti asi líbilo, není vůbec možné.
Co naopak podle mě možné je, je definovat konkurenční výpočet (třeba v IO monádě) tak, aby k race condition nedocházelo, ale to je problém, jehož řešení není v silách čistého FP jako takového.
-
To je svět, který je úplně mimo dosah matematické funkce a proto snaha "smířit" reálný svět se světem čistě funkcionálním tak, jak by se Ti asi líbilo, není vůbec možné.
Mě včera napadlo, že možná není od věci si připomenout základ: matematická funkce není žádný "výpočet" nebo "operace". Matematická funkce je relace. Je to statická záležitost, tabulka vazeb parametry - výsledek. Matematická funkce se nedá "spustit", nemůže provést žádnou operaci, výpočet. Asi líp než u Haskellu je to vidět u Prologu, kde je program vlastně úplně statická záležitost (v tomhle popsaným smyslu), teprve inferenční engine je to, co "běží", co z programu dělá nějaký proces. A pokud chce člověk inferenční engine donutit k nějaké konkrétní posloupnosti činností, tak je to makačka na bednu, často se v tom udělá chyba a je to celkem citelný znásilňování té samotné základní (deklarativní) koncepce jazyka.
Ne že by to bylo něco, co byste nevěděli, ale když si to člověk připomene, tak se možná na tu race condition dívá trochu z jinýho úhlu :)
-
V Dartu to jsou ještě kovariantní generika - typový systém povolí kontravarianci, ale za běhu to spadne. Například
Jasně, už to chápu. Prostě tam není syntaxe pro specifikaci variance a přijímá se, že to případně zbuchne až v provozu :)
V tom odkazu o Dartu se to píše docela bez obalu:
We don’t consider any of these ways in current use to be suitable for a language meant to be approachable, and whose type annotations are meant to be simple, lightweight, and optional. Really very few programmers of any kind find it natural or easy to write variance annotations or wildcarding (I don’t myself).
Čili "nechceme vyděsit JavaScriptisty" ;) Chápu, ale moc velký sympatie to ve mně teda nevyvolává :)
-
No to je zajímavá otázka - jestli by šlo nějak zabezpečit, aby jazyk předal runtimu zaručeně jenom takové instrukce, které by zaručeně nevedly k race condition. Pokud myslíš RC obecně (síť, paměť, disk, čekání na zprávy...) tak si to fakt neumím představit :) Třeba chytré hlavy už něco vymyslely, akorát to zas bude mít nějaké jiné neblahé praktické důsledky ;)
To si dokážu představit zcela jasně, za předpokladu runtime v jednovláknovém OS, jako třeba MS-DOS. V současných OS ne.
Mě včera napadlo, že možná není od věci si připomenout základ: matematická funkce není žádný "výpočet" nebo "operace". Matematická funkce je relace. Je to statická záležitost, tabulka vazeb parametry - výsledek.
Potom není od věci připomenout si, že celý počítač je matematická funkce CPU zapsaná v booleově algebře, provádějící miliardkrát za sekundu přechod state := CPU(state) kde state je asi 20 000 bitů. Automaticky z toho vyplývá odpověď na problematiku race condition a proč to funkcionální programování nikdy nemůže vyřešit.
-
To si dokážu představit zcela jasně, za předpokladu runtime v jednovláknovém OS, jako třeba MS-DOS. V současných OS ne.
Já si to dovedu (mlhavě) představit i v současných OS - klasické řešení je provádět citlivé operace atomicky nebo zamykat. Otázka zní, jak by to šlo dobře dohromady s tím FP jako takovým, jestli takové věci jdou dělat formálně (dokazatelně) správně, jak moc by takový program šel optimalizovat... Otázky, otázky, samé otázky :)))
Potom není od věci připomenout si, že celý počítač je matematická funkce CPU zapsaná v booleově algebře, provádějící miliardkrát za sekundu přechod state := CPU(state) kde state je asi 20 000 bitů. Automaticky z toho vyplývá odpověď na problematiku race condition a proč to funkcionální programování nikdy nemůže vyřešit.
Mně tam ta automatičnost nějak nevyvstává, už proto, že takhle napsáno je to "jednovláknová" věc, kde k RC dojít nemůže :)
Klíčový na tom všem je to odlišení jazyka jako takového a úrovně běhu (sémantiky, runtimu) - a jestli když si vymyslím, že bych chtěl dosáhnout nějaké vlastnosti běhu, tak jak dobře (a korektně) se to dá "mapovat" do jazyka... Třeba silný typový systém jazyka mi garantuje, že runtime nebude hledat v paměti něco, co tam není. Třeba by nějaký podobný fígl šel použít i na ty RC...
-
To si dokážu představit zcela jasně, za předpokladu runtime v jednovláknovém OS, jako třeba MS-DOS. V současných OS ne.
Já si to dovedu (mlhavě) představit i v současných OS - klasické řešení je provádět citlivé operace atomicky nebo zamykat. Otázka zní, jak by to šlo dobře dohromady s tím FP jako takovým, jestli takové věci jdou dělat formálně (dokazatelně) správně, jak moc by takový program šel optimalizovat... Otázky, otázky, samé otázky :)))
Potom není od věci připomenout si, že celý počítač je matematická funkce CPU zapsaná v booleově algebře, provádějící miliardkrát za sekundu přechod state := CPU(state) kde state je asi 20 000 bitů. Automaticky z toho vyplývá odpověď na problematiku race condition a proč to funkcionální programování nikdy nemůže vyřešit.
Mně tam ta automatičnost nějak nevyvstává, už proto, že takhle napsáno je to "jednovláknová" věc, kde k RC dojít nemůže :)
Klíčový na tom všem je to odlišení jazyka jako takového a úrovně běhu (sémantiky, runtimu) - a jestli když si vymyslím, že bych chtěl dosáhnout nějaké vlastnosti běhu, tak jak dobře (a korektně) se to dá "mapovat" do jazyka... Třeba silný typový systém jazyka mi garantuje, že runtime nebude hledat v paměti něco, co tam není. Třeba by nějaký podobný fígl šel použít i na ty RC...
co třeba Software transactional memory?
v Haskellu ve formě STM monády, velmi příjemná záležitost
-
co třeba Software transactional memory?
v Haskellu ve formě STM monády, velmi příjemná záležitost
To by asi mohlo být ono. V Erlangu se zas na to jde tak, že pokud je nějaký prostředek, který neumí konkurenci sám o sobě, tak se mu přiřadí řídící proces (erlangovský light proces), ostatní procesy jenom posílají zprávy a dostávají odpovědi, takže je to celý korektně serializovaný jenom díky tomu, jak probíhá štosování zpráv... Jelikož je posílání zpráv dostatečně rychlý, funguje to taky dobře. Jenže pak jsou "čisté" jenom ty procesy uvnitř, ne program jako celek, takže čumil by nad tím určitě ohrnoval nos ;)
-
Já si to dovedu (mlhavě) představit i v současných OS - klasické řešení je provádět citlivé operace atomicky nebo zamykat.
User space současných OS nedovolí potřebnou úroveň atomicity a zamykání, to je jeho smysl aby to nešlo.
Mně tam ta automatičnost nějak nevyvstává, už proto, že takhle napsáno je to "jednovláknová" věc, kde k RC dojít nemůže :)
Klíčový na tom všem je to odlišení jazyka jako takového a úrovně běhu (sémantiky, runtimu) - a jestli když si vymyslím, že bych chtěl dosáhnout nějaké vlastnosti běhu, tak jak dobře (a korektně) se to dá "mapovat" do jazyka... Třeba silný typový systém jazyka mi garantuje, že runtime nebude hledat v paměti něco, co tam není. Třeba by nějaký podobný fígl šel použít i na ty RC...
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 :)
To by asi mohlo být ono. V Erlangu se zas na to jde tak, že pokud je nějaký prostředek, který neumí konkurenci sám o sobě, tak se mu přiřadí řídící proces (erlangovský light proces), ostatní procesy jenom posílají zprávy a dostávají odpovědi, takže je to celý korektně serializovaný jenom díky tomu, jak probíhá štosování zpráv...
V Erlangu se proto nevedou diskuze, všichni vidí jak se věci mají ;)
-
V Erlangu se proto nevedou diskuze, všichni vidí jak se věci mají ;)
No ale ten erlangovský přístup je právě příkladem, jak se dá dosáhnout atomicity*, takže je to v rozporu s tím, co píšeš výš.
* samozřejmě ne takové té superkorektní jako u databází - s rollbackem apod., ale to neva
-
No ale ten erlangovský přístup je právě příkladem, jak se dá dosáhnout atomicity
Cíle se dosáhnout dá, ale ne s prostředky jazyka. Nepěkné nepohodlné věci se vystrčí ven z jazyka a komunikuje se s nimi přes nějaké rozhraní. Mají to tak všude, i v C/C++, i v C#, i v Javě, i v Erlangu. Rozdíl je jen v tom kdo si to již přiznal a kdo dosud ne :)
-
Cíle se dosáhnout dá, ale ne s prostředky jazyka. Nepěkné nepohodlné věci se vystrčí ven z jazyka a komunikuje se s nimi přes nějaké rozhraní.
Jenze mezi tou "vystrcenou veci" a jazykem muze byt nejake mapovani, stejne jako u toho silneho typovani. Typovani je vlastne jenom ciste abstraktni vec a presto mi zarucuje nejake zalezitosti "vne jazyka".
Rozdíl je jen v tom kdo si to již přiznal a kdo dosud ne :)
Tak ja myslim, ze jsme tady o tom vsichni mluvili otevrene, ze Haskell vytvori nejaky predpis, ktery uz se provadi vlastne mimo samotny jazyk. Nevsiml jsem si, ze by to tady nekdo zastiral nebo nechapal.
-
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.
-
Typovani je vlastne jenom ciste abstraktni vec a presto mi zarucuje nejake zalezitosti "vne jazyka".
Teoreticky asi ano, prakticky se obávám že ne ;)
-
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.
Já osobně si ty omezení dobře uvědomuju. Neflamil jsem tu proto, že bych monády považoval za něco neprůstřelného. Jen mi vadilo, že nám tu čumil otloukal o hlavu, jaké elegantní řešení my tupci přehlížíme. A přítom jím navrhované věci trpí +-úplně tím stejným.
-
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.
-
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?
-
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ě.
-
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?
-
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.
-
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ů :)
-
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.
-
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ě ;)
-
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.
-
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í?
-
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.
-
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í.)
-
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.)
-
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 :P
-
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 :P
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?
-
IO Monáda umožní souběh.
To s vhodnou interpretací umožní libovolný matematický objekt - třeba číslo 1.
-
IO Monáda umožní souběh. To ti nepřijde jako porušení referenční transparentnosti?
Monáda právě souběh (pochopil jsem jako více "vláken" výpočtu) neumožňuje. Je tam právě kvůli vynucení sekvenčního zpracování. Více vláken je v Haskellu udělané tak, že je monáda obejita. Respektive je vytvořen ještě jeden IO objekt, který o tom prvním nic neví. Dokud nezavoláš některou z funkcí, která tu monádu obchází, monáda ti garantuje že k souběhu nedojde.
U IO v Haskellu není ta referenční transparentnost omezená funkcemi jako spíš jejich vstupem.
-
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.)
Teď ti nerozumím. Nebo nevím, čemu říkáš "pure funkce". Pokud pod "pure funkce" myslíš "matematická funkce", tak ta opravdu podle mě nemůže vykonávat žádnou činnost. Jak už jsem říkal, matematická funkce je relace.
Např. můžeš mít funkci {{1,2},{2,3},{3,4},{4,5},...} - tahle funkce NEpřičítá jedničku. Jenom říká, že symboly "1" a "2" jsou v relaci "přičtení jedničky" (chceme-li "relace následník").
K tomu, aby byla vykonávána nějaká činnost, musí existovat nějaký stroj, "výkonný mechanismus" apod., který něco od někud načte, něco někam zapíše apod. Jasně, může to dělat podle nějakého popisu, postupu, klidně i té relace, ale potřebuje mít k tomu popisu nějakou sémantiku, nějak ten popis interpretovat.
...takže třeba ta otázka, jestli tenhle celý cirkus "umožňuje souběhy" je podle mýho (možná špatnýho) dojmu otázka po vlastnostech toho "stroje", ne toho statického popisu ("relace").
Jak jsem už psal, na Prologu je to vidět imho líp - představ si, že bys měl nějaký čistě deklarativní logický jazyk ve stylu Prologu a dva různé inferenční enginy ("runtimy"), které by oba šly směrem k řešení jinou cestou - "funkce" v programu by pak byly stejné, ale běh programu by byl v těch dvou případech jiný. Tohle je u deklarativních jazyků v principu možný. Samozřejmě je to nežádoucí, takže se jazyk vymyslí tak, aby měl sémantiku jednoznačnou - což je podobný jako princip té monády, která je takový trik, který ti umožňuje zafixovat něco, co by jinak zafixované nebylo.
(Nevylučuju, že jsem ti jenom špatně rozuměl, nebo se v něčem mýlím. Za doplnění/upřesnění budu rád.)
-
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.
-
IO Monáda umožní souběh. To ti nepřijde jako porušení referenční transparentnosti?
Monáda právě souběh (pochopil jsem jako více "vláken" výpočtu) neumožňuje. Je tam právě kvůli vynucení sekvenčního zpracování. Více vláken je v Haskellu udělané tak, že je monáda obejita. Respektive je vytvořen ještě jeden IO objekt, který o tom prvním nic neví. Dokud nezavoláš některou z funkcí, která tu monádu obchází, monáda ti garantuje že k souběhu nedojde.
U IO v Haskellu není ta referenční transparentnost omezená funkcemi jako spíš jejich vstupem.
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ý?
Abych zase nebyl nepochopen. Já chápu, že side efekty se blbě zakomponovávají do FP. Chápu, že se to musí nějak udělat. A nemám problém mět dva oddělené světy, jeden sluníčkový, a druhý s těma efektama. Ale tak nějak vám mám pocit, že těmi IOMonádami se to propojení fakt nepovedlo. Původně, ještě když jsem s Haskellem začínal, tak jsem měl za to, že IOMonády nějak zabalují interakci s tím vnějším zlým světem, tak, aby s tím mohl sluníčkový pracovat. Teď mám dojem, že je to naopak jezinka, která skrze dva prstíčky se infiltruje a zničí spolehlivost sluníčkového světa. Že ta izolace je teoretická, a v praxi to kompilátoři nezvládají.
-
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ů.
-
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.
-
Čistota jazyka nezávisí na tom, jak interpretujete výsledky programů.
Možná by se dala použít i takováhle alegorie: představme si, že čistý funkcionální program generuje céčkovský kód, který se poté spustí. To generování je jenom operace nad nějakou strukturou, takže to můžu bez problémů dělat čistě. A v tom céčkovském kódu už zase klíďopíďo můžu mít interakce s vnějším světem, vedlejší efekty, ...
Dalo by se to takhle říct? Já mám za to, že jo.
-
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ý?
Podle mě tam máš zbytečně silný předpoklad. Paralelizace se snadno implementuje tam, kde nemáš sdílený stav. To ale nutně neimplikuje úplně čisté funkce. Je víc možností. Stav může být sdílený jenom v rámci nějaké menší jednotky (a pak ty jednotky můžou fungovat paralelně vůči sobě, ale ne uvnitř), nebo se může komunikovat přes nějaká API, která paralelizaci umožní.
Na tohle je právě skvělý příklad Erlang - čistotu tam nemáš skoro žádnou a přitom paralelizovatelnost je víc než uspokojivá ;)
-
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.)
Teď ti nerozumím. Nebo nevím, čemu říkáš "pure funkce". Pokud pod "pure funkce" myslíš "matematická funkce", tak ta opravdu podle mě nemůže vykonávat žádnou činnost. Jak už jsem říkal, matematická funkce je relace.
Např. můžeš mít funkci {{1,2},{2,3},{3,4},{4,5},...} - tahle funkce NEpřičítá jedničku. Jenom říká, že symboly "1" a "2" jsou v relaci "přičtení jedničky" (chceme-li "relace následník").
K tomu, aby byla vykonávána nějaká činnost, musí existovat nějaký stroj, "výkonný mechanismus" apod., který něco od někud načte, něco někam zapíše apod. Jasně, může to dělat podle nějakého popisu, postupu, klidně i té relace, ale potřebuje mít k tomu popisu nějakou sémantiku, nějak ten popis interpretovat.
...takže třeba ta otázka, jestli tenhle celý cirkus "umožňuje souběhy" je podle mýho (možná špatnýho) dojmu otázka po vlastnostech toho "stroje", ne toho statického popisu ("relace").
Jak jsem už psal, na Prologu je to vidět imho líp - představ si, že bys měl nějaký čistě deklarativní logický jazyk ve stylu Prologu a dva různé inferenční enginy ("runtimy"), které by oba šly směrem k řešení jinou cestou - "funkce" v programu by pak byly stejné, ale běh programu by byl v těch dvou případech jiný. Tohle je u deklarativních jazyků v principu možný. Samozřejmě je to nežádoucí, takže se jazyk vymyslí tak, aby měl sémantiku jednoznačnou - což je podobný jako princip té monády, která je takový trik, který ti umožňuje zafixovat něco, co by jinak zafixované nebylo.
(Nevylučuju, že jsem ti jenom špatně rozuměl, nebo se v něčem mýlím. Za doplnění/upřesnění budu rád.)
Myslím, že se na to díváme podobně. Já jen tak explicitně neodděluji předpis od jeho vykonání.
Jak jsem psal na jiném místě, beru to tak, že Haskell jako jazyk/předpis, je funkcionálně čistý. A to dokonce včetně IOMonád. Je to předpis, jak něco nějak vykonat atd... přesně jak jsi to pěkně popsal.
A pak máš engine, ať už interpret, nebo kompilátor, který se snaží ten předpis zpracovat. A ideální by bylo, aby se ten engine choval přesně podle toho předpisu. Takže:
1. Mám funkci sum :: Int -> Int -> Int, která mi sečte dvě čísla. A já logicky očekávám, že ten engine mi pro sum 1 1 vrátí 2ku. Ať si to vevnitř spočítá jak chce. Ať tam používá sdílenou paměť, ať ji mění, ať se třeba ptá google, to je mi fuk. Ale nesmí se stát, že mi vyhodí chybu. To prostě nejde.
2. Když budu mět funkci parseXml :: String -> Either String Xml tak já tam na první pohled mám možnost vyhodit chybu, jenže už na druhý je jasné, že pokud uvedu parseXml "<empty/>", tak mi to vždycky hodí Right Xml. Takže tam není nic na výběr. Ten výběr je jen pro programátora, aby se mu s tím lépe pracovalo.
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.
Ano, uvědomuji si, že to nejsou úplně skvělé příklady, ale až mě napadne lepší, tak ho sem strčím.
-
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.
-
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 :)
-
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?
-
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.
-
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 ;)
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 [{"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.
-
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?
-
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.
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 :)
-
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 [{"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.
-
Hele, nemůžeme si tykat?
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í.
* pokud by pro ně jazyk neměl nějakou úplně explicitní syntax, která by vůbec nebyla funkcí, ale něčím úplně odlišným, nějakou speciální konstrukcí.
P.S. už to raději nebudu dál rozvíjet a půjdu spát, nechme to uležet :) Raději nechám taky prostor kolegům, pořád mám trochu svrbění, jestli jsem někde v té úvaze neudělal chybu, která by si zasloužila uvést na pravou míru :)
-
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?
-
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.
...a už toho vážně nechám :) dobrou noc a díky za debatu!
-
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.
-
a tudíž je IMHO pure
Ještě jednou: purity je podle mýho vlastnost jazyka a nedává žádný smysl ji vztahovat na runtime.
-
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?
-
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 :)
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.
...a už ale fakt dobrou! :))
-
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.
-
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á.
Jop, přesně tak. Jím vyzdvihovaný Clean neumožňuje race conditions. Ale ne proto že by ho UT nějak vylučoval. Prostě tam zatím nikdo ty plnotučná vlákna neimplementoval. Jen paralelní vyhodnocování výrazů, které je principilelně slabší a tím i bezpečnější.
Ty se domníváš, že jazyk nemůže zakázat souběh tak nějak z principu? Nebo jak to myslíš?
Svým způsobem může, ale není to až tak užitečné. I když zakážeme souběh uvnitř programu, stále je tu souběh se vším co běží mimo něj. IMO je to moc omezení a ve výsledku toho moc nepřinese.
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?
Je to ošéfované tak, že na základě typu C funkce očekává Haskell po zavolání funkce v registru RAX výsledný int. Pokud tam nebude, tak spokojeně schroupe jakýkoliv odpad, co tam najde. Nemá šanci poznat že je na tom intu něco špatně.
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.
-
Svým způsobem může, ale není to až tak užitečné. I když zakážeme souběh uvnitř programu, stále je tu souběh se vším co běží mimo něj. IMO je to moc omezení a ve výsledku toho moc nepřinese.
Já bych celkem trval na tom, že ani tak nemůže :) Neumožnit to můžeš jedině na úrovni runtimu prostě tak, že tam nebude žádná funkce, která by spouštěla nové vlákno, nebudou tam C pluginy a nebudeš moct pouštět OS volání. 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í.
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
-
Rust vs. race condition:
https://news.ycombinator.com/item?id=7009502
všimněte si jak rozlišují "race condition" a "data race"
poznámka bokem - překládalo se "race condition" vždycky jako "souběh"? na střední jsme tomu říkali "hazard" nebo "hazardní stav"
-
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
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
Zatím jsem na Elm koukal jenom zběžně, ale když si přeložím marketingové žvásty do češtiny tak to nevypadá nic moc. Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
-
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á píšu hodně v Elixiru, teď hlavně nástroj na event management (něco na způsob Logstash) + k němu webový rozhraní. Tohle je docela velkej projekt. Plus mám v Elixiru ještě hromadu všelijakých menších věcí. Když jsme u toho, pokud by někdo měl zájem, dost bych bral někoho, kdo by měl chuť se podílet na https://github.com/mprymek/symconfig (je to ve fázi proof of concept, pre-alpha. Tady na tom githubu je starší verze, teď už je to o kousek dál, jenom jsem to ještě nezveřejnil). Příklad použití: https://github.com/mprymek/symconfig-example1
Akorát teda nevím, jestli Elixir počítáš do funkcionálních jazyků :)
Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
Není to spíš tak, že se s chybami počítá předem, musíš je ošetřit a nepřekvapí tě až při běhu?
-
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í.
-
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.
-
Odporuješ si. Pokud typem zajistíš, že nedojde k souběhu, a runtime to pak nedodrží tak jsi zase na začátku.
Říkal jsem, že nevím, jestli je to vůbec možné, pomocí typového systému něco takového garantovat, popř. do jaké míry, zas tak moc do té teorie nevidím, o tom by se musel rozepsat asi spíš Radek...
Runtime musí dodržet sémantiku jazyka. Nemůže si dělat co chce. Může dělat cokoli, ale jenom tak, aby zachoval význam programu.
Ono stačí prohlásit, že předpis je funkcionální, a už nesmí dojít k souběhu.
Já vlastně nevím, co tohle tvrzení říká. Asi bys to musel rozepsat víc formálně, abysme vůbec věděli, o čem je řeč.
-
Ono stačí prohlásit, že předpis je funkcionální, a už nesmí dojít k souběhu.
Já vlastně nevím, co tohle tvrzení říká. Asi bys to musel rozepsat víc formálně, abysme vůbec věděli, o čem je řeč.
k výzvě se připojuju, hlavní problém je z mého pohledu nejasnost definic, aji nějaké ty kousky kódu demonstrující debatované problémy by nezaškodily
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
Zatím jsem na Elm koukal jenom zběžně, ale když si přeložím marketingové žvásty do češtiny tak to nevypadá nic moc. Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
V čistém kódu pokud to chápu správně nemohou být exceptions. Takže Elm to řeší pomocí Maybe a Either. A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
-
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
Já psal v Haskellu úpravy syntaktického stromu a generování GLSL. Snažil jsem se o genetickou optimalizaci shaderů a automatické přehazování výpočtů mezi nimi. Výsledek stál za starou bačkoru, ale ne zásluhou FP. Díky FP jsem jen velice rychle zjistil že tudy cesta pravděpodobně nevede. A odnesl jsem si silné pohrdání visitor patternem, páč jsem pak můj kód porovnával se shader optimizerem :)
Není to spíš tak, že se s chybami počítá předem, musíš je ošetřit a nepřekvapí tě až při běhu?
Možná jo. Akorát mi tam pak nesedí ta zmínka o crash.
Když se kouknu na http://package.elm-lang.org/packages/elm-lang/core/2.1.0/Task tak mám jakýsi pocit dejavu :) Monád poznám i když se bind přejmenuje na andThen :P
-
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
Já osobně jsem udělal jednodušší IDE a teď dělám interpretr takového malého bezvýznamného jazyka. Na nic link nedám, protože to opravdu není hezký kód, nejsem zatím mistr, a také to není dodělané. Obojí v Haskellu.
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
Zatím jsem na Elm koukal jenom zběžně, ale když si přeložím marketingové žvásty do češtiny tak to nevypadá nic moc. Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
V čistém kódu pokud to chápu správně nemohou být exceptions. Takže Elm to řeší pomocí Maybe a Either. A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
jestli se vám takhle plete IO do kódu v Haskellu, tak něco děláte blbě, já mám v IO monádě u překladače cca 180 řádků (z cca 10k) a to je moc a až se jednou budu hodně nudit, tak to vyčistím na 50 max. (sosnout argumenty a vstupní soubory, vyplivnout binárku)
-
V čistém kódu pokud to chápu správně nemohou být exceptions.
Můžou. Může to být jenom syntaktický cukříček nad tím že každá funkce vrací např (Either X Error). Dá se to tak i implementovat.
Takže Elm to řeší pomocí Maybe a Either.
Takový Haskell taky. A díky tomu, že jsou to tam monády se dá většina testů vygenerovat automaticky stylem jedna operce selže, zbytek se přeskočí a celek selže taky.
A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
A co takhle imperativní Task? Porovnej si typy funkcí kolem Tasku s funkcema kolem IO. Task se dá akorát parametrizovat i chybovou hodnotou. Jinak je to na jedno kopyto.
-
Rust vs. race condition:
https://news.ycombinator.com/item?id=7009502
všimněte si jak rozlišují "race condition" a "data race"
poznámka bokem - překládalo se "race condition" vždycky jako "souběh"? na střední jsme tomu říkali "hazard" nebo "hazardní stav"
Ano, to jsem popletl, typový systém Rustu (pokud ho neobejdete) zabrání data racům i v programu s více vlákny - nikoliv souběhům.
-
V čistém kódu pokud to chápu správně nemohou být exceptions.
Můžou. Může to být jenom syntaktický cukříček nad tím že každá funkce vrací např (Either X Error). Dá se to tak i implementovat.
Takže Elm to řeší pomocí Maybe a Either.
Takový Haskell taky. A díky tomu, že jsou to tam monády se dá většina testů vygenerovat automaticky stylem jedna operce selže, zbytek se přeskočí a celek selže taky.
A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
A co takhle imperativní Task? Porovnej si typy funkcí kolem Tasku s funkcema kolem IO. Task se dá akorát parametrizovat i chybovou hodnotou. Jinak je to na jedno kopyto.
Vidíte, to mne nenapadlo. Já proti monádám nic nemám. To si zase nemyslete. A Task není imperativní, on nedělá žádné vedlejší efekty. Obsahuje pouze informace o tom, co se má udělat, a myslím že to lze i asynchronně. A tyto Tasky jsou poté pomocí signálů poslané do výstupních portů běhového prostředí, které už rozkazy vykoná, a případnou reakci zase pošle skrz vstupní porty z kterých je signály zase rozešlou do zbytku programu. Všechno je krásně čisté.
-
A Task není imperativní, on nedělá žádné vedlejší efekty. Obsahuje pouze informace o tom, co se má udělat [...] A tyto Tasky jsou poté pomocí signálů poslané do výstupních portů běhového prostředí, které už rozkazy vykoná, a případnou reakci zase pošle skrz vstupní porty z kterých je signály zase rozešlou do zbytku programu. Všechno je krásně čisté.
...což je prakticky to samé jako IO monáda ;)
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
Zatím jsem na Elm koukal jenom zběžně, ale když si přeložím marketingové žvásty do češtiny tak to nevypadá nic moc. Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
V čistém kódu pokud to chápu správně nemohou být exceptions. Takže Elm to řeší pomocí Maybe a Either. A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
jestli se vám takhle plete IO do kódu v Haskellu, tak něco děláte blbě, já mám v IO monádě u překladače cca 180 řádků (z cca 10k) a to je moc a až se jednou budu hodně nudit, tak to vyčistím na 50 max. (sosnout argumenty a vstupní soubory, vyplivnout binárku)
To nepochybuji že dělám plno věcí špatně, jsem konec konců začátečník. Ale když děláte IDE, musíte mít GUI, a takové i primitivní GUI pomocí gtk2hs je opravdu na hodně řádků kódu. A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
-
A Task není imperativní, on nedělá žádné vedlejší efekty. Obsahuje pouze informace o tom, co se má udělat [...] A tyto Tasky jsou poté pomocí signálů poslané do výstupních portů běhového prostředí, které už rozkazy vykoná, a případnou reakci zase pošle skrz vstupní porty z kterých je signály zase rozešlou do zbytku programu. Všechno je krásně čisté.
...což je prakticky to samé jako IO monáda ;)
Musím nesouhlasit. Není to jako IO monáda. Neumím to blíže vysvětlit. Musí se to zkusit.
-
A Task není imperativní, on nedělá žádné vedlejší efekty. Obsahuje pouze informace o tom, co se má udělat [...] A tyto Tasky jsou poté pomocí signálů poslané do výstupních portů běhového prostředí, které už rozkazy vykoná, a případnou reakci zase pošle skrz vstupní porty z kterých je signály zase rozešlou do zbytku programu. Všechno je krásně čisté.
...což je prakticky to samé jako IO monáda ;)
Musím nesouhlasit. Není to jako IO monáda. Neumím to blíže vysvětlit. Musí se to zkusit.
asi mám stack overflow nebo něco, o jakém Tasku to mluvíte?
-
To nepochybuji že dělám plno věcí špatně, jsem konec konců začátečník. Ale když děláte IDE, musíte mít GUI, a takové i primitivní GUI pomocí gtk2hs je opravdu na hodně řádků kódu. A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
To je celkem známý problém, že IO je "virální". Záleží na typu řešeného problému, jak moc se to projeví. "v" srovnává nesrovnatelné - překladač je prakticky "batch processing", tam není problém. U interaktivnějších záležitostí, jako je právě to IDE, to problém je. Možná by mohl pomoct ten reaktivní přístup - oddělit věci, které provádí IO a pomocí něčeho na způsob channelů pak posílat do kódu, který už může být čistý. Ale chápu, že se to snadněji řekne, než udělá, jsem si toho vědom, nechci dávat knížečí rady, je to jenom poznámka na okraj, když už tady to reaktivní programování zaznělo...
Musím nesouhlasit. Není to jako IO monáda. Neumím to blíže vysvětlit. Musí se to zkusit.
Vždycky je to de facto variace na nějakou lambdu. Vytvoří se nějaké lambdy a ty se v runtimu spustí, čímž se provede to vlastní IO. Jak přesně je to uděláno je detail, ale vždycky je to něco na tenhle způsob, protože to ani jinak nejde :)
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
Zatím jsem na Elm koukal jenom zběžně, ale když si přeložím marketingové žvásty do češtiny tak to nevypadá nic moc. Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
V čistém kódu pokud to chápu správně nemohou být exceptions. Takže Elm to řeší pomocí Maybe a Either. A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
jestli se vám takhle plete IO do kódu v Haskellu, tak něco děláte blbě, já mám v IO monádě u překladače cca 180 řádků (z cca 10k) a to je moc a až se jednou budu hodně nudit, tak to vyčistím na 50 max. (sosnout argumenty a vstupní soubory, vyplivnout binárku)
To nepochybuji že dělám plno věcí špatně, jsem konec konců začátečník. Ale když děláte IDE, musíte mít GUI, a takové i primitivní GUI pomocí gtk2hs je opravdu na hodně řádků kódu. A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
GUI jde asi blbě, uznávám, sám jsem zatím vždycky pokušení zkoušet to v Haskellu odolal (a doufám, že mi to vydrží i do budoucna), myslím, že kvůli takovým věcem vymysleli FRP
interpreter imperativního jazyka je už ale trochu jiný případ, konkrétně měnitelné reference v AST IMHO nejsou potřeba, resp. na co je potřebujete?
-
A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
IO monádu nepotřebujete, můžete si udělat vlastní monádu, která bude podporovat jen omezený počet akcí, a tu pak interpretovat v IO monádě.
V principu podobné, ale jednodušší je udělat handler jako funkci Stav -> (Stav, [Akce]), kde Stav popisuje stav aplikace nebo jeho část a Akce popisuje akci, která se má provést po doběhnutí handleru. GUI pak bude funkce stavu - tj. typu Stav -> GUI - podobně jako to má React.
-
Čistota jazyka nezávisí na tom, jak interpretujete výsledky programů.
Možná by se dala použít i takováhle alegorie: představme si, že čistý funkcionální program generuje céčkovský kód, který se poté spustí. To generování je jenom operace nad nějakou strukturou, takže to můžu bez problémů dělat čistě. A v tom céčkovském kódu už zase klíďopíďo můžu mít interakce s vnějším světem, vedlejší efekty, ...
Dalo by se to takhle říct? Já mám za to, že jo.
A v tomto zmysle potom môžeme C vyhlásiť za čistý funkcionálny jazyk. Pravda, pokiaľ ho chápeme spolu s C predprocesorom, ale ten je tam už od dôb Kernighana a Ritchieho. ;D
http://conal.net/blog/posts/the-c-language-is-purely-functional (http://conal.net/blog/posts/the-c-language-is-purely-functional)
-
Čistota jazyka nezávisí na tom, jak interpretujete výsledky programů.
Možná by se dala použít i takováhle alegorie: představme si, že čistý funkcionální program generuje céčkovský kód, který se poté spustí. To generování je jenom operace nad nějakou strukturou, takže to můžu bez problémů dělat čistě. A v tom céčkovském kódu už zase klíďopíďo můžu mít interakce s vnějším světem, vedlejší efekty, ...
Dalo by se to takhle říct? Já mám za to, že jo.
A v tomto zmysle potom môžeme C vyhlásiť za čistý funkcionálny jazyk. Pravda, pokiaľ ho chápeme spolu s C predprocesorom, ale ten je tam už od dôb Kernighana a Ritchieho. ;D
http://conal.net/blog/posts/the-c-language-is-purely-functional (http://conal.net/blog/posts/the-c-language-is-purely-functional)
No bodejť, vždyť v C je všechno funkce :-D
-
Čistota jazyka nezávisí na tom, jak interpretujete výsledky programů.
Možná by se dala použít i takováhle alegorie: představme si, že čistý funkcionální program generuje céčkovský kód, který se poté spustí. To generování je jenom operace nad nějakou strukturou, takže to můžu bez problémů dělat čistě. A v tom céčkovském kódu už zase klíďopíďo můžu mít interakce s vnějším světem, vedlejší efekty, ...
Dalo by se to takhle říct? Já mám za to, že jo.
Tohle je dost chytrý trollpost. A do značné míry i pravdivý. Rozdíl je v tom, že cpp je hloupý preprocesor a Haskell je úžasně chytrý preprocesor a zatímco ten první neumí vyjádřit velkou část složitého programu samotného tak, aby bylo možno rozumně rozhodnout o jeho korektnosti, u toho druhého to možné je. Druhý rozdíl je v tom, že generovaný jazyk je v tom druhém případě podstatně "hezčí" a kód v něm napsaný verifikovatelnější, ale ten první rozdíl považuji za zásadní.
A v tomto zmysle potom môžeme C vyhlásiť za čistý funkcionálny jazyk. Pravda, pokiaľ ho chápeme spolu s C predprocesorom, ale ten je tam už od dôb Kernighana a Ritchieho. ;D
http://conal.net/blog/posts/the-c-language-is-purely-functional (http://conal.net/blog/posts/the-c-language-is-purely-functional)
-
Čistota jazyka nezávisí na tom, jak interpretujete výsledky programů.
Možná by se dala použít i takováhle alegorie: představme si, že čistý funkcionální program generuje céčkovský kód, který se poté spustí. To generování je jenom operace nad nějakou strukturou, takže to můžu bez problémů dělat čistě. A v tom céčkovském kódu už zase klíďopíďo můžu mít interakce s vnějším světem, vedlejší efekty, ...
Dalo by se to takhle říct? Já mám za to, že jo.
A v tomto zmysle potom môžeme C vyhlásiť za čistý funkcionálny jazyk. Pravda, pokiaľ ho chápeme spolu s C predprocesorom, ale ten je tam už od dôb Kernighana a Ritchieho. ;D
http://conal.net/blog/posts/the-c-language-is-purely-functional
Omlouvám se za špatně vložený text v předchozí reakci, možno případně smazat, mělo to být takhle:
Tohle je dost chytrý trollpost. A do značné míry i pravdivý. Rozdíl je v tom, že cpp je hloupý preprocesor a Haskell je úžasně chytrý preprocesor a zatímco ten první neumí vyjádřit velkou část složitého programu samotného tak, aby bylo možno rozumně rozhodnout o jeho korektnosti, u toho druhého to možné je. Druhý rozdíl je v tom, že generovaný jazyk je v tom druhém případě podstatně "hezčí" a kód v něm napsaný verifikovatelnější, ale ten první rozdíl považuji za zásadní.
-
Tohle je dost chytrý trollpost. A do značné míry i pravdivý.
Já bych naopak řekl, že je silně matoucí. Mám-li zdroják v Haskellu a přeložím ho, dostanu zjevně ne-funkcionální strojový kód. "Funkcionálnost" je vlastnost zdrojáku, ne přeloženého programu.
C rozhodně není funkcionální jazyk v žádném smyslu, i kdyby se nakrásně stalo, že zdroják v C a zdroják v Haskellu se přeloží na stejný strojový kód.
-
Tohle je dost chytrý trollpost. A do značné míry i pravdivý.
Já bych naopak řekl, že je silně matoucí. Mám-li zdroják v Haskellu a přeložím ho, dostanu zjevně ne-funkcionální strojový kód. "Funkcionálnost" je vlastnost zdrojáku, ne přeloženého programu.
C rozhodně není funkcionální jazyk v žádném smyslu, i kdyby se nakrásně stalo, že zdroják v C a zdroják v Haskellu se přeloží na stejný strojový kód.
Jenže já se nebavím o C, ale o makrojazyku cpp (preprocesoru). Ten přece produkuje něco podobného jako program v Haskellu s IO monádou, tedy popis (obecně stavového) procesu, který se rozběhne po překladu do binárního kódu, zavedení do paměti a předání řízení operačním systémem. Tak jsem pochopil i ten odkazovaný článek, ten chce ukázat, že vinou IO monády, která do programu v Haskellu zavádí čas a stav a kterou jsme si (alespoň někteří) zde ukázali jako předpis pro interpreter, jak vést výpočetní akci, je funkcionální Haskell v zásadě pouze preprocesorem pro tu "imperativní akci". A zrovna tak i cpp, který je v zásadě čistě funkcionální, připravuje takovou akci vygenerováním výsledného rozvinutého zdrojového programu v C. Je to trochu extrémní a účelová paralela, ale mimo mi nepřijde.
-
Jenže já se nebavím o C, ale o makrojazyku cpp (preprocesoru).
Aha, sorry, to mi nějak nedocvaklo.
A zrovna tak i cpp, který je v zásadě čistě funkcionální
Není, v cpp žádným program nenapíšeš. Funguje to jenom díky tomu, že tam jsou velké kusy přímo C. Btw, cpp není ani turingovsky kompletní: http://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete
Je to prostě zavádějící příklad.
-
To nepochybuji že dělám plno věcí špatně, jsem konec konců začátečník. Ale když děláte IDE, musíte mít GUI, a takové i primitivní GUI pomocí gtk2hs je opravdu na hodně řádků kódu. A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
To je celkem známý problém, že IO je "virální". Záleží na typu řešeného problému, jak moc se to projeví. "v" srovnává nesrovnatelné - překladač je prakticky "batch processing", tam není problém. U interaktivnějších záležitostí, jako je právě to IDE, to problém je. Možná by mohl pomoct ten reaktivní přístup - oddělit věci, které provádí IO a pomocí něčeho na způsob channelů pak posílat do kódu, který už může být čistý. Ale chápu, že se to snadněji řekne, než udělá, jsem si toho vědom, nechci dávat knížečí rady, je to jenom poznámka na okraj, když už tady to reaktivní programování zaznělo...
Musím nesouhlasit. Není to jako IO monáda. Neumím to blíže vysvětlit. Musí se to zkusit.
Vždycky je to de facto variace na nějakou lambdu. Vytvoří se nějaké lambdy a ty se v runtimu spustí, čímž se provede to vlastní IO. Jak přesně je to uděláno je detail, ale vždycky je to něco na tenhle způsob, protože to ani jinak nejde :)
Souhlasím, vše je variace na lambdu. Ale v reaktivitě tečou data tak jak mají téct v matematické funkci. V případě Haskellu se to tak neděje. A to je ten rozdíl o kterém jsem mluvil.
-
Jestli Vám mohu skočit do řeči. Když jsem si detailně pročítal tuto diskuzi. Narazil jsem na další způsob IO v čistém jazyce. Mluvil o tom čumil. Reaktivita. Má s ní někdo tady zkušenost? Zkoušel jsem čumilem doporučovaný jazyk Elm, a je to opravdu hodně, hodně zajímavé z mého laického pohledu.
Zatím jsem na Elm koukal jenom zběžně, ale když si přeložím marketingové žvásty do češtiny tak to nevypadá nic moc. Konkrétně třeba "No runtime exceptions". Ten jazyk se vážně chlubí tím, že buď všechno perfektně funguje nebo to naprosto neopravitelně padne na hubu? Na webové appky asi dobrý, no ... ::)
V čistém kódu pokud to chápu správně nemohou být exceptions. Takže Elm to řeší pomocí Maybe a Either. A je to fakt úžasný, když píšu, cítím se jako když píšu funkcionálně, a nemám takový divný pocit jako když píšu něco v Haskellu a plete se mi do toho imperativní IO.
jestli se vám takhle plete IO do kódu v Haskellu, tak něco děláte blbě, já mám v IO monádě u překladače cca 180 řádků (z cca 10k) a to je moc a až se jednou budu hodně nudit, tak to vyčistím na 50 max. (sosnout argumenty a vstupní soubory, vyplivnout binárku)
To nepochybuji že dělám plno věcí špatně, jsem konec konců začátečník. Ale když děláte IDE, musíte mít GUI, a takové i primitivní GUI pomocí gtk2hs je opravdu na hodně řádků kódu. A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
GUI jde asi blbě, uznávám, sám jsem zatím vždycky pokušení zkoušet to v Haskellu odolal (a doufám, že mi to vydrží i do budoucna), myslím, že kvůli takovým věcem vymysleli FRP
interpreter imperativního jazyka je už ale trochu jiný případ, konkrétně měnitelné reference v AST IMHO nejsou potřeba, resp. na co je potřebujete?
Přímo v AST měnitelné reference nemám. Ale v jmenném prostředí už ano. Takže jsem to řekl špatně, to ale nemění nic na faktu, že tam mám IO velmi mnoho, a vlastně krom parsování a serializování jsem to mohl dělat v C++ a měl bych to rychlejší a tak trošku stejné co se týče podoby kódu. Tou podobou myslím obecné chování kódu.
-
A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
IO monádu nepotřebujete, můžete si udělat vlastní monádu, která bude podporovat jen omezený počet akcí, a tu pak interpretovat v IO monádě.
V principu podobné, ale jednodušší je udělat handler jako funkci Stav -> (Stav, [Akce]), kde Stav popisuje stav aplikace nebo jeho část a Akce popisuje akci, která se má provést po doběhnutí handleru. GUI pak bude funkce stavu - tj. typu Stav -> GUI - podobně jako to má React.
Ale jistě. Tak jako lze Haskell přeložit do impure jazyka, tak jde i skutečně čistý jazyk přeložit do Haskellu. Ale já jakožto pracující člověk, věnující se Haskellu o svém volném čase prostě nemám čas vytvářet si wrapper nad existujícími GUI knihovnami.Něco takového by prostě měl nabídnout už jazyk sám, ne spoléhat že si v tom jazyce uděláme čisté prostředí sami. Nováčci jako já jsou poté akorát zmatení, a zklamaní, protože nechápou jak ten jazyk může být čistý. Ve skutečnosti to znamená že si v něm můžeme čistý jazyk udělat, ne že je. Nezbývá mi než se přidat k panu xyz a říci že C je taky čistě funkcionální.
-
A zrovna tak i cpp, který je v zásadě čistě funkcionální
Není, v cpp žádným program nenapíšeš. Funguje to jenom díky tomu, že tam jsou velké kusy přímo C. Btw, cpp není ani turingovsky kompletní: http://stackoverflow.com/questions/3136686/is-the-c99-preprocessor-turing-complete
No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. ;D
Je to prostě zavádějící příklad.
To si nemyslím. Ten príspevok na jeho blogu je vcelku k veci, aj keď je písaný so značnou dávkou nadsádzky. Okrem toho si nemyslím, že by čitateľom tohto vlákna (ak sem nezablúdili omylom) neboli jasné či už tebou alebo Inkvizitorom uvádzané námietky.
-
No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. ;D
Když si představím něco jiného, tak pro to bude i něco jiného platit, to dá rozum :) Je to jako bys řekl, že Eiffelovka je zmrzlina a na námitku, že je z kovu a nedá se moc lízat bys řekl "tak si představ Eiffelovku z mraženého mlíka" :)
Podle mě tohle prostě debatu nijak nevyjasňuje, spíš naopak. Téma je už tak složitý a plný různých nuancí, tak by bylo lepší ho nezamlžovat...
-
No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. ;D
Když si představím něco jiného, tak pro to bude i něco jiného platit, to dá rozum :) Je to jako bys řekl, že Eiffelovka je zmrzlina a na námitku, že je z kovu a nedá se moc lízat bys řekl "tak si představ Eiffelovku z mraženého mlíka" :)
Podle mě tohle prostě debatu nijak nevyjasňuje, spíš naopak. Téma je už tak složitý a plný různých nuancí, tak by bylo lepší ho nezamlžovat...
Debata už bylo zamlžená dost z mého pohledu. Cítím z ní stejný pocit jako cítím z Haskellu. Napřed se objevil čumil, a začal vcelku logicky uvádět věci na pravou míru. Protože to ale dělal se skutečnou vervou, rozhodlo se pár místních mistrů z něj prostě udělat blba. To se nepovedlo protože radši odešel, a debata ve své zmatenosti pokračovala dále. Závěr je ten, že čumil říkal že Haskell není čistý, a měl snadno pochopitelné argumenty a dokonce vypsal řešení problému, ostatní zde tvrdili že Haskell je čistý, a podporovali to argumenty které jsem moc nechápal, byly na mne moc složité řekl bych, podobně jako některé vysvětlení na internetu proč je Haskell čistý. A na závěr jsem se zde dověděl, že vlastně IO monáda je pro GUI nevýhodná, a že pro to je FRP o kterém nazačátku mluvil čumil. K tomu všemu jsem se dozvěděl že vlastně FRP je takřka to samé co IO monáda. Citím se neskutečně otráveně a unaveně, myslím, že přesně to je jeden z důvodů proč se funkcionální jazyky nepoužívají, já bych ho také nepoužil, po zkušenostech s Haskellem. To už radši nasadím libovolný z dnešních jazyků, a budu mít to samé, a rychlejší. To co zde píšu zní zmateně, a přesně takový i jsem z této debaty. Spíš mi přišlo že si tady pár lidí vyřizovalo osobní učty.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
-
No tak si namiesto C/CPP predstav C/FPP, kde FPP je čisto funkcionálny predprocesor, trebárs doplnenie CPP o nejaký SK-kalkulus: bude to čisto funkcionálne aj turingovsky úplné. Nemusí to byť moc praktické - na riešenie praktických vecí z neslniečkového sveta tu predsa máme abstraktný typ C. ;D
Když si představím něco jiného, tak pro to bude i něco jiného platit, to dá rozum :)
Aj preto si myslím, že ti táto jednoduchá modifikácia musela byť zrejmá ešte predtým, než som ti o nej napísal. Mám teda za to, že sme si vyjasnili, že pre C/FPP tvoje námietky padajú.
Podle mě tohle prostě debatu nijak nevyjasňuje, spíš naopak.
A to si práve nemyslím.
Téma je už tak složitý a plný různých nuancí, tak by bylo lepší ho nezamlžovat...
Možno by pomohlo, keby si vysvetlil, v čom presne vidíš to zahmlievanie. Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú. (A samozrejme, hovoríme všeobecne o akomsi prípadnom, tebou predpokladanom, zahmlievaní pre čitateľov tohto fóra.)
-
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.
V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.
Samozřejmě obecně může být potřeba rozhodnout HP, abyste zjistil, zda se chování programu nezmění, když výraz nahradíte jeho hodnotou. U běžných jazyků to však nebývá problém.
-
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.
Jak jsem už tady kdesi psal, je to jako adorovat jako superbezpečný OS, který nepodporuje komunikaci po síti, a říkat, že to je daleko lepší než OS, který komunikaci po síti podporuje (a tím se vystavuje nebezpečí).
byly na mne moc složité řekl bych, podobně jako některé vysvětlení na internetu proč je Haskell čistý. [...] Citím se neskutečně otráveně a unaveně, myslím, že přesně to je jeden z důvodů proč se funkcionální jazyky nepoužívají,
No však tohle je taková "metadebata" o aspektech, který pro samotný programování nijak moc rozumět nemusíš. Když bys neměl moc zkušeností s OOP a přichomítl se k nějaké debatě třeba o těch záměrných nedokonalostech typového systému Swiftu, tak bys tomu taky nerozuměl. To přece není důvod nad tím úplně zlomit hůl...
A na závěr jsem se zde dověděl, že vlastně IO monáda je pro GUI nevýhodná, a že pro to je FRP o kterém nazačátku mluvil čumil.
No ale FRP mu nikdo nevyvracel, to může být dobré řešení, akorát je otázka, jakého problému a jak přesně použité. To už čumil nerozebral. Jenom tak plácnout "FRP" a tvářit se, že jsem tím něco vyřešil, žádné řešení ničeho není :) A mimochodem, FRP jde samozřejmě dělat i v Haskellu, takže to není nic proti němu :)
K tomu všemu jsem se dozvěděl že vlastně FRP je takřka to samé co IO monáda.
Ne, tady byla pointa jiná: pokud chceš mít čistý jazyk a zároveň ovlivňovat okolní svět, tak vždycky skončíš u toho, že budeš mít nějaký runtime, který bude spouštět nějaký předpis, který mu tím čistým způsobem vygeneruješ. V tomhle je to stejné, jinak se to samozřejmě v různých praktických aspektech může lišit. A nevím o tom, že by to šlo dělat nějak jinak, takže nemá smysl tímhle povyšovat jedno řešení nad jiné.
-
To už radši nasadím libovolný z dnešních jazyků, a budu mít to samé, a rychlejší.
To je naprosto v pořádku. Pokud ti nějaký přístup nevyhovuje, použij ten, který ti vyhovuje, to je naprosto správně. Rychlejší to být nemusí právě v případě, že budeš chtít masivně paralelizovat. Tam s OOP dost brzo narazíš.
Možno by pomohlo, keby si vysvetlil, v čom presne vidíš to zahmlievanie.
Myslím, že nemá smysl rozebírat do kdovíjaké hloubky jednu alegorii, která v jednom aspektu může sedět a ve spoustě jiných být úplně mimo...
-
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íš?
-
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 ;)
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ě.
-
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?
-
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á.
-
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.
-
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é.
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í.
-
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í.
-
Zatímco u Unique typingu to ideově vadí.
No a tohle omezení můžeš úplně klidně k monadickému řešení přidat a máš totéž (imho). To je ta pointa. Vezmeš Linux, vyhážeš z něj drivery pro síťovky a máš rázem SuperBezpečnýNehacknutelnýSystém(R), daleko lepší než Linux!
-
Zatímco u Unique typingu to ideově vadí.
No a tohle omezení můžeš úplně klidně k monadickému řešení přidat a máš totéž (imho). To je ta pointa.
Vtip je v tom, že nemůžeš.
-
Vtip je v tom, že nemůžeš.
Proč?
-
Vtip je v tom, že nemůžeš.
Proč?
Nepřekračoval by si její (ideovou) zodpovědnost?
-
Nepřekračoval by si její (ideovou) zodpovědnost?
Myslím že ne, protože stačí k tomu forku prostě nedát nástroj. Ale nejsem haskellista, v tomhle se můžu mýlit.
-
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.
V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.
To je vcelku jasné, napokon to zaznelo už aj v tomto vlákne. Toho sa moja reakcia netýkala. Samotná znalosť definície ešte nezaručuje jasnosť či pochopenie pojmu. Napríklad, z predstavy spojitej funkcie ako funkcie "ktorej graf sa netrhá" možno dôjsť k definícii, ktorá je vcelku jednoduchá a logická. Problém môže nastať vo chvíli, keď narazíme na Cantorovu funkciu či Riemannovu funkciu a zrazu zistíme, že naše pochopenie pojmu nebolo zďaleka také dobré, ako sme si mysleli. A problém nie je v definícii alebo v náročnosti dôkazu spojitosti/nespojitosti pri týchto funkciách, ale v tom, že výsledky sú iné ako by sme intuitívne očakávali.
Blog, ktorý som odkazoval, naznačil, že čosi podobné nás môže stretnúť pri čistom funkcionálnom jazyku. Ako odpoveď som (bez akéhokoľvek vysvetlenia) dostal, že uvedený príklad debatu nijako nevyjasňuje, ale naopak zahmlieva. No a toho sa týkala moja vyššie citovaná reakcia, na ktorú som však (presne podľa očakávania) aj tak nijakú odpoveď nedostal.
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,...
A nepotrebuješ ich ani pri lenivom vyhodnocovaní, ako ukazuje príklad Mirandy.
-
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.
V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.
keď narazíme na Cantorovu funkciu či Riemannovu funkciu a zrazu zistíme, že naše pochopenie pojmu nebolo zďaleka také dobré
Možná, ale zatím jsme na žádný takový příklad nenarazili, nebo ano?
-
Možno zistíme, že ten pocit zahmlievania pramení len z toho, že veci, ktoré sa nám zdali jasné a dobre pochopené, až tak jasné či dobre pochopené nie sú.
V principu to je velmi jednoduché - stačí znát definici jazyka - tj. typový systém, termy, hodnoty, redukci a na základě toho určíte, zda je jazyk čistě funkcionální.
keď narazíme na Cantorovu funkciu či Riemannovu funkciu a zrazu zistíme, že naše pochopenie pojmu nebolo zďaleka také dobré
Možná, ale zatím jsme na žádný takový příklad nenarazili, nebo ano?
To závisí od toho, či nám tá Cantorova alebo Riemannova funkcia naozaj pripadá divná alebo nie. Ako ukazuje diskusia v tomto vlákne (ale aj na iných fórach), tak čistota Haskellu jednoznačne mnohým ľuďom divná pripadá. Čím, pravdaže, nevylučujem, že niekomu by nemusel pripadať divný ani funkcionálne čistý jazyk "obsahujúci C-čko".
-
To závisí od toho, či nám tá Cantorova alebo Riemannova funkcia naozaj pripadá divná alebo nie. Ako ukazuje diskusia v tomto vlákne (ale aj na iných fórach), tak čistota Haskellu jednoznačne mnohým ľuďom divná pripadá. Čím, pravdaže, nevylučujem, že niekomu by nemusel pripadať divný ani funkcionálne čistý jazyk "obsahujúci C-čko".
Nebylo by lepší opustit ty mlhavé analogie a napsat to polopaticky? V čem Haskell není čistý? Zatím jsme narazili jenom na to, že forknutí IO je nečisté (což je jasný z principu). Něco dál? A v jakém smyslu by měl být čistý "funkcionální jazyk obsahující céčko"? Jak by měl vypadat? V čem by se od Haskellu lišil?
-
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?
A není to řešení jakési neuspokojivé? Stejným způsobem by se přece daly vyřešit problémy s paralelismem i v C :
#define pthread_create trhni_si_nohou
Už tu padlo asi tisíckrát, že Haskell bez použití vláken je v tomhle identický s Cleanem.
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).
Pokud si alokuješ objekt na haldě, tak unique typing zajistí že ti na něj může ukazovat jeden jediný ukazatel. Takových objektů na haldě můžeš mít milion ale na každý bude ukazovat jenom jeden ukazatel.
V cleanu se to využívá tak, že se vytvoří objekt Svět. Každá funkce co dělá IO ho bere jako parametr a vrací. Protože ten ukazatel může být jenom jeden, tak se ty io funkce dají jenom spojit jedna za druhou. A teď překvapení : V IO monádě je schovaný přesně takovýhle objekt. Jenom tam ta unikátnost není zajištěná speciálním pravidlem jazyka ale omezenou sadou funkcí, ktrýma se dají IO akce kombinovat.
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.
Unique typing vlákna neřeší, protože se stará jen o jeden objekt. Pokud má každé vlákno vlastní World objekt, je to unique typingu úplně putna. V tomhle jsou Haskell a Clean jako přes kopírák. Clean te "řeší" tak, že tam ty vlákna prostě zatím nikdo neimplementoval. Tohle si bohužel může dovolit jen experimentální jazyk, který skoro nikdo nepoužívá.
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í.
Ideově to nevadí unique typingu. Ideově to může vadit maximálně tak někomu, kdo si plete vlastnosti UT a singletonu. Milion objektů typu Svět, pro každé vlákno jeden, je podle UT 100% správně. Pokud teda na každý bude ukazovat jediný ukazatel, ale to monády zvládnou zajistit taky.
Monády a UT jsou trochu něco jiného, ale v tomhle případě jsou jejich výsledky naprosto stejné.
-
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?
A není to řešení jakési neuspokojivé? Stejným způsobem by se přece daly vyřešit problémy s paralelismem i v C :
#define pthread_create trhni_si_nohou
Už tu padlo asi tisíckrát, že Haskell bez použití vláken je v tomhle identický s Cleanem.
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).
Pokud si alokuješ objekt na haldě, tak unique typing zajistí že ti na něj může ukazovat jeden jediný ukazatel. Takových objektů na haldě můžeš mít milion ale na každý bude ukazovat jenom jeden ukazatel.
V cleanu se to využívá tak, že se vytvoří objekt Svět. Každá funkce co dělá IO ho bere jako parametr a vrací. Protože ten ukazatel může být jenom jeden, tak se ty io funkce dají jenom spojit jedna za druhou. A teď překvapení : V IO monádě je schovaný přesně takovýhle objekt. Jenom tam ta unikátnost není zajištěná speciálním pravidlem jazyka ale omezenou sadou funkcí, ktrýma se dají IO akce kombinovat.
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.
Unique typing vlákna neřeší, protože se stará jen o jeden objekt. Pokud má každé vlákno vlastní World objekt, je to unique typingu úplně putna. V tomhle jsou Haskell a Clean jako přes kopírák. Clean te "řeší" tak, že tam ty vlákna prostě zatím nikdo neimplementoval. Tohle si bohužel může dovolit jen experimentální jazyk, který skoro nikdo nepoužívá.
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í.
Ideově to nevadí unique typingu. Ideově to může vadit maximálně tak někomu, kdo si plete vlastnosti UT a singletonu. Milion objektů typu Svět, pro každé vlákno jeden, je podle UT 100% správně. Pokud teda na každý bude ukazovat jediný ukazatel, ale to monády zvládnou zajistit taky.
Monády a UT jsou trochu něco jiného, ale v tomhle případě jsou jejich výsledky naprosto stejné.
Je to jen taková poznámka. Něco co mne napadlo. Koukal jsem se na unique typing a myslím že jsem ho vcelku pochopil. My nemůže zkopírovat objekt World prostě proto, že zkopírovat svět nejde, objekt World je jen reference na svět, ne samotný svět, a podle UT s objektem musí pracovat pouze jedno jediné vlákno. Kdyby jsme zkopírovali World, budou existovat dvě reference na ten skutečný svět, a tím pádem už to nebude UT, protože s objektem bude pracovat více vláken.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
-
Je to jen taková poznámka. Něco co mne napadlo. Koukal jsem se na unique typing a myslím že jsem ho vcelku pochopil. My nemůže zkopírovat objekt World prostě proto, že zkopírovat svět nejde, objekt World je jen reference na svět, ne samotný svět, a podle UT s objektem musí pracovat pouze jedno jediné vlákno. Kdyby jsme zkopírovali World, budou existovat dvě reference na ten skutečný svět, a tím pádem už to nebude UT, protože s objektem bude pracovat více vláken.
A tady leží ten zásadní problém. O objektu World se dá uvažovat jako o singletonu. S tím ale UT nijak nepomůže. Ten umí zaručit že na objekt bude existovat jediná reference. Ale těch jednotlivých objektů může být neomezeně.
Pro jazyk je objekt World naprosto normální entita. Netuší že je to fake reprezentace něčeho jiného. Dá se jich vytvořit libovolné množství. Jediné co tomu brání je, že to ještě nikdo nenapsal. Není to nic za co by mohlo UT. UT řeší jen unikátnost "ukazatelů". Neřeší to, na co ty ukazatele ukazují.
-
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
Tohle : http://forum.root.cz/index.php?topic=11417.msg134558#msg134558
Ano, má tam spoustu věcí správně ale taky dost zásadní chyby. Třeba to o mutable proměnných v bodu 3. Ano, Haskell je umí a Clena je neumí jen proto že je tam zatím nikdo neimplementoval. Pokud jsou v něčem soubory, tak mutable proměnné taky musí jít. Je úplně jedno, co přesně jsou ty malé kousky stavu co program mění. UT tomu nijak nebrání. Ani s referenční transparentností na tom jsou monády úplně stejně. Výraz s objektem world se nahradit návratovou hodnotou nedá, protože world v principu závisí na čase a stavu celého světa v daném čase.
Ty Lazy streams taky nejsou žádná ultimátní stříbrná kulka. Jsou blbě rozšiřitelné, s jedním streamem může pracovat jenom jedno vlákno.
Ano, obecné věci o FP tam má dobře. Akorát v těch detailech má kopec chyb. A ty detaily nám tu otloukal o hlavu s takovou vervou, že to dopadlo tímhle flamem.
-
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
Tohle : http://forum.root.cz/index.php?topic=11417.msg134558#msg134558
Ano, má tam spoustu věcí správně ale taky dost zásadní chyby. Třeba to o mutable proměnných v bodu 3. Ano, Haskell je umí a Clena je neumí jen proto že je tam zatím nikdo neimplementoval. Pokud jsou v něčem soubory, tak mutable proměnné taky musí jít. Je úplně jedno, co přesně jsou ty malé kousky stavu co program mění. UT tomu nijak nebrání. Ani s referenční transparentností na tom jsou monády úplně stejně. Výraz s objektem world se nahradit návratovou hodnotou nedá, protože world v principu závisí na čase a stavu celého světa v daném čase.
Ty Lazy streams taky nejsou žádná ultimátní stříbrná kulka. Jsou blbě rozšiřitelné, s jedním streamem může pracovat jenom jedno vlákno.
Ano, obecné věci o FP tam má dobře. Akorát v těch detailech má kopec chyb. A ty detaily nám tu otloukal o hlavu s takovou vervou, že to dopadlo tímhle flamem.
Děkuji za shrnutí. Zajímavé. Dává to smysl, mutable proměnná se dá udělat i pomocí souborů. Když se na to koukám takto, ani Clean nebude skutečně čistý, protože nezabraňuje tady tomu problému. Jak říkal čumil to o tom vytékání dat vstupem, Clean to bude umožňovat i přes UT taky. Zajímavé. A proč by nemohly být lazy streams ultimátní stříbrná kulka? Runtime může rozkaz vykonat v kolika vláknech chce. A samotný funkcionální kód má zase svoje metody jak běžet paralelně. V tomto nevidím problém. Pletu se někde?
-
Je to jen taková poznámka. Něco co mne napadlo. Koukal jsem se na unique typing a myslím že jsem ho vcelku pochopil. My nemůže zkopírovat objekt World prostě proto, že zkopírovat svět nejde, objekt World je jen reference na svět, ne samotný svět, a podle UT s objektem musí pracovat pouze jedno jediné vlákno. Kdyby jsme zkopírovali World, budou existovat dvě reference na ten skutečný svět, a tím pádem už to nebude UT, protože s objektem bude pracovat více vláken.
A tady leží ten zásadní problém. O objektu World se dá uvažovat jako o singletonu. S tím ale UT nijak nepomůže. Ten umí zaručit že na objekt bude existovat jediná reference. Ale těch jednotlivých objektů může být neomezeně.
Pro jazyk je objekt World naprosto normální entita. Netuší že je to fake reprezentace něčeho jiného. Dá se jich vytvořit libovolné množství. Jediné co tomu brání je, že to ještě nikdo nenapsal. Není to nic za co by mohlo UT. UT řeší jen unikátnost "ukazatelů". Neřeší to, na co ty ukazatele ukazují.
Závěr, pokud to správně chápu, je ten, že jak IO monáda v Haskellu, tak UT v Cleanu vykazují známky nečistoty. Akorát UT se tváří že je čistější než IO monáda, ale ve výsledku není.
-
vykazují známky nečistoty
Podle jaké definice? Musí to být definice absurdní, protože pokud IO jako takové, samo o sobě znamená nečistotu, potom čistý může být jenom program bez IO - čili program, který nic neumí vyprodukovat, nic neumí vypočítat... Ok, může být, akorát taková čistota pak asi není něco, o co by kdokoli stál...
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
-
vykazují známky nečistoty
Podle jaké definice? Musí to být definice absurdní, protože pokud IO jako takové, samo o sobě znamená nečistotu, potom čistý může být jenom program bez IO - čili program, který nic neumí vyprodukovat, nic neumí vypočítat... Ok, může být, akorát taková čistota pak asi není něco, o co by kdokoli stál...
neinteraktivní není neužitečný :)
-
neinteraktivní není neužitečný :)
No jo, jenže podle téhle definice čistoty by nešel ani batch processing :)
-
vykazují známky nečistoty
Podle jaké definice? Musí to být definice absurdní, protože pokud IO jako takové, samo o sobě znamená nečistotu, potom čistý může být jenom program bez IO - čili program, který nic neumí vyprodukovat, nic neumí vypočítat... Ok, může být, akorát taková čistota pak asi není něco, o co by kdokoli stál...
Čumil tu definici moc hezky napsal. Podle matematické definice. Oboje metody podle mích zkušeností umožňují dělat nedeterministické funkce. V Cleanu nemám zkušenosti, ale jak JSH napsal, je to takřka to samé co IO monáda. A navíc, IO lze dělat. Jen vypadá výrazně jinak, než na co jsme my programátoři odkojení na klasických jazycích zvyklí.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
-
Čumil tu definici moc hezky napsal.
Myslíš tu, kterou Haskell splňuje?
http://forum.root.cz/index.php?topic=11417.msg134755#msg134755
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
-
Čumil tu definici moc hezky napsal.
Myslíš tu, kterou Haskell splňuje?
http://forum.root.cz/index.php?topic=11417.msg134755#msg134755
Můžete si říkat co chcete, já nejsem zažraný teoretik. Když můžu v Haskellu napsat kód, který vypadá a chová se úplně stejně jako kód napsaný v Cčku, tak Haskell prostě není pure. Alespoň pro mne jako pro obyčejného programátora. To už bych mohl odůvodnění proč je Haskell pure naroubovat i na Cčko. A to by se pak člověku vysmál každý řekl bych. Nejsem jediný programátor který je Haskellem silně zmaten.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?
-
Když můžu v Haskellu napsat kód, který vypadá a chová se úplně stejně jako kód napsaný v Cčku, tak Haskell prostě není pure.
No, to je dost zvláštní tvrzení. Představ si, že bys měl main funkci, která by vracela "seznam IO akcí" - načti tohle, vraž to sem, zapiš tohle tam. Výsledkem main funkce by byl jenom tenhle seznam. což je statická abstraktní struktura, kterou jistě můžeš generovat čistě.
...no a tuhle strukturu prostě vezmeš a v runtimu uděláš ty akce. Co je na tom teda nečistého a podle jaké definice?
No a tohle je v podstatě přesně to, co IO monáda dělá.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?
import Control.Monad.State
f = evalState g 0
where g = do
a <- get
put 1
b <- get
return (a, b)
main = print f
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
-
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Ovšem to "a <- get" není, pokud se nepletu, normální volání normální funkce. Takže to "různá volání stejné funkce vrátí jinou hodnotu" je přinejmenším zavádějící.
Teď si z hlavy nevybavím, jak to tam přesně je, ale v principu to bude syntaktický cukr pro dvoje volání nějaké lambdy s různými parametry.
-
Když můžu v Haskellu napsat kód, který vypadá a chová se úplně stejně jako kód napsaný v Cčku, tak Haskell prostě není pure.
No, to je dost zvláštní tvrzení. Představ si, že bys měl main funkci, která by vracela "seznam IO akcí" - načti tohle, vraž to sem, zapiš tohle tam. Výsledkem main funkce by byl jenom tenhle seznam. což je statická abstraktní struktura, kterou jistě můžeš generovat čistě.
...no a tuhle strukturu prostě vezmeš a v runtimu uděláš ty akce. Co je na tom teda nečistého a podle jaké definice?
No a tohle je v podstatě přesně to, co IO monáda dělá.
Když jsem se koukal na vnitřní implementaci IO monády, tak mi to přišlo jako prostá kompozice lambd. A to se od lazy streams dost liší. V případě lazy streams člověk do runtimu nezasahuje, nemá do něj přístup, prostě jen řekne co chce. V případě IO monády člověk to podhoubí pracující se světem sám píše. Neříká co chce, jen přes wrapper přímo volá Cčkovské funkce. Opět zdůrazňuji, jsem jen uživatel Haskellu se selským rozumem, nepochybuji že pomocí vhodných argumentů by se můj dojem dal roztrhat na cucky. Ale pro mne by to nic nezměnilo, jakožto uživatel se budu potýkat se stejnými problémy jako doteď.
-
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Ovšem to "a <- get" není, pokud se nepletu, normální volání normální funkce. Takže to "různá volání stejné funkce vrátí jinou hodnotu" je přinejmenším zavádějící.
Teď si z hlavy nevybavím, jak to tam přesně je, ale v principu to bude syntaktický cukr pro dvoje volání nějaké lambdy s různými parametry.
když vyjdu z čumilovy definice monády tak to jsou dvě volání stejné funkce se stejnými argumenty v pozměněném prostředí
-
Neříká co chce, jen přes wrapper přímo volá Cčkovské funkce.
No a to právě AFAIK není pravda. Z té funkce, která dělá IO (např. main) prostě vypadnou ty lambdy. Ty v kódu NEvoláš céčkovské funkce, ale vytváříš lambdy, které předáš runtimu.
(pokud se mýlím, doufám, že mě zkušenější kolegové poopraví)
Ale pro mne by to nic nezměnilo, jakožto uživatel se budu potýkat se stejnými problémy jako doteď.
Monády dělají jenom iluzi imperativního kódu. Všechno je to jenom syntaktický cukr. Třeba "return" není žádný return. Kdyby sis místo do blocku to celé rozepsal do těch lambd, tak by tě to třeba tak nedráždilo a tu čistotu byz nezpochybňoval, protože bys ji tam měl jak na talíři :)
-
když vyjdu z čumilovy definice monády tak to jsou dvě volání stejné funkce se stejnými argumenty v pozměněném prostředí
Tady o žádnou čumilovu definici nejde. Význam symbolu "<-" je jasně definovaný, čumil nečumil ;) A dvoje volání téže funkce se stejnými parametry to prostě není.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?
import Control.Monad.State
f = evalState g 0
where g = do
a <- get
put 1
b <- get
return (a, b)
main = print f
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Koukal jsem se na to, a nikde nevidím měnitelný stav. Když si to rozepíšeme pomocí klasických monadických operátorů, jasně uvidíme že měnitelný stav tam není, jen se vytvářejí nové kopie State monády, která v sobě má jiný stav, takže funkce get pokaždé vrátí něco jiného. Je zavolána s jinou instancí State monády.
f = evalState g 0
where g =
get >>= (\a ->
put 1 >>
get >>= (\b ->
return (a, b)))
main = print f
-
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Ovšem to "a <- get" není, pokud se nepletu, normální volání normální funkce. Takže to "různá volání stejné funkce vrátí jinou hodnotu" je přinejmenším zavádějící.
Teď si z hlavy nevybavím, jak to tam přesně je, ale v principu to bude syntaktický cukr pro dvoje volání nějaké lambdy s různými parametry.
když vyjdu z čumilovy definice monády tak to jsou dvě volání stejné funkce se stejnými argumenty v pozměněném prostředí
Monády slouží pro zřetězení operací v nějakém kontextu, vždyť se to o nich i říká v oficiální dokumentaci. To nevymyslel čumil. Ale vnitřně monády nemají měnitelný stav. A ani navenek, při každé změně nová kopie. I ty měnitelný reference jsou neměnný, ale to na co ukazují již ano.
-
Neříká co chce, jen přes wrapper přímo volá Cčkovské funkce.
No a to právě AFAIK není pravda. Z té funkce, která dělá IO (např. main) prostě vypadnou ty lambdy. Ty v kódu NEvoláš céčkovské funkce, ale vytváříš lambdy, které předáš runtimu.
(pokud se mýlím, doufám, že mě zkušenější kolegové poopraví)
Ale pro mne by to nic nezměnilo, jakožto uživatel se budu potýkat se stejnými problémy jako doteď.
Monády dělají jenom iluzi imperativního kódu. Všechno je to jenom syntaktický cukr. Třeba "return" není žádný return. Kdyby sis místo do blocku to celé rozepsal do těch lambd, tak by tě to třeba tak nedráždilo a tu čistotu byz nezpochybňoval, protože bys ji tam měl jak na talíři :)
Vytvořit lambdu která volá Cčkovskou funkci není čisté, a rozhodně o nic víc než zavolání té funkce rovnou. A runtimu se nic nepředává, runtime Haskellu nemá žádný modul pro IO. A i kdyby se předávalo, na faktu že v čistém jazyce píšeme kód s vedlejšími efekty se nic nezmění.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?
import Control.Monad.State
f = evalState g 0
where g = do
a <- get
put 1
b <- get
return (a, b)
main = print f
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Koukal jsem se na to, a nikde nevidím měnitelný stav. Když si to rozepíšeme pomocí klasických monadických operátorů, jasně uvidíme že měnitelný stav tam není, jen se vytvářejí nové kopie State monády, která v sobě má jiný stav, takže funkce get pokaždé vrátí něco jiného. Je zavolána s jinou instancí State monády.
f = evalState g 0
where g =
get >>= (\a ->
put 1 >>
get >>= (\b ->
return (a, b)))
main = print f
jak víte, že tam není měnitelný stav? jak víte, že u ioref v io monádě je? co když na tom nezáleží?
-
a co kdybych v příkladu použil ST monádu?
-
Neříká co chce, jen přes wrapper přímo volá Cčkovské funkce.
No a to právě AFAIK není pravda. Z té funkce, která dělá IO (např. main) prostě vypadnou ty lambdy. Ty v kódu NEvoláš céčkovské funkce, ale vytváříš lambdy, které předáš runtimu.
(pokud se mýlím, doufám, že mě zkušenější kolegové poopraví)
Ale pro mne by to nic nezměnilo, jakožto uživatel se budu potýkat se stejnými problémy jako doteď.
Monády dělají jenom iluzi imperativního kódu. Všechno je to jenom syntaktický cukr. Třeba "return" není žádný return. Kdyby sis místo do blocku to celé rozepsal do těch lambd, tak by tě to třeba tak nedráždilo a tu čistotu byz nezpochybňoval, protože bys ji tam měl jak na talíři :)
Čistotu IO monády jsem začal zpochybňovat od té doby, co jsem ji začal používat i k něčemu složitějšímu než čtení a zapisování do konzole. Ačkoli, já jsem ji nezačal zpochybňovat, já jsem se snažil zoufale pochopit jak to může být funkcionální. Řešení je prosté, není. A rozepsání nic nemění. Po rozepsání to sice nebude vypadat jak kód v Cčku, ale chovat se bude stejně.
-
vstup/výstup v čistě a čistěji funkcionálních jazycích je složitý problém, jaké překvapení
čumil nic nemohl uvést na pravou mírou bo tomu sám nerozumí, viz jeho dlouhý post a to co psal o měnitelných referencích v IO monádě
A co o nich psal špatného? Mne se jeho logika příjemně chápala, byla jasná a stručná. Prosím, neříkejte o někom že něčemu vůbec nerozumí, já bych si něco takového už jen z pohledu vlastních zkušeností nedovolil. A vy máte zkušenosti podobné jako já, pokud vycházím z vytvořených projektů.
uvedl měnitelné reference jako důkaz nečistototy io monády, ale ty se dají implementovat i ve State monádě, která je 100% čistá, krom toho je to v rozporu s definicí kterou sám uvedl - funkce v prostředí, zápis do reference způsobí změnu prostředí
Zajímavé. Mohl by jste to první více vysvětlit? A druhou část komentáře jsem bohužel nepochopil.
ve State monádě lze implementovat měnitelné reference, funkce jako createVar, readVar, writeVar, uvedel jsem tayd kus kódy, který demonstruje kdy v čistém kódu dvě různá volání stejné funkce vrátí jinou hodnotu
O tom nic nevím. Byl by jste tak hodný, a napsal delší okomentovanou ukázku?
import Control.Monad.State
f = evalState g 0
where g = do
a <- get
put 1
b <- get
return (a, b)
main = print f
vypíše (0,1), tj. get vrátí pokaždé jinou hodnotu, přesto je f čistá funkce, čarodějnictví?!
Koukal jsem se na to, a nikde nevidím měnitelný stav. Když si to rozepíšeme pomocí klasických monadických operátorů, jasně uvidíme že měnitelný stav tam není, jen se vytvářejí nové kopie State monády, která v sobě má jiný stav, takže funkce get pokaždé vrátí něco jiného. Je zavolána s jinou instancí State monády.
f = evalState g 0
where g =
get >>= (\a ->
put 1 >>
get >>= (\b ->
return (a, b)))
main = print f
jak víte, že tam není měnitelný stav? jak víte, že u ioref v io monádě je? co když na tom nezáleží?
U IORef to vím jistě protože jsem ji dost používal, tam prostě není možné dělat nové kopie IORef, člověk ji používá aby se ty kopie právě nedělali, jinak by komunikace mezi handlery nefungovala. Zkuste si napsat GUI aplikaci, budete ji muset použít taky, a měnitelný stav na vás bude křičet. A nakonec, záleží na tom, to je také možné pak říci, vždyť na čistotě nezáleží, pojďme na C++.
-
a co kdybych v příkladu použil ST monádu?
Z toho co jsem si přečetl, tak ST monáda je kapsa nečistoty v čistém kódu. Může být v čistém kódu, protože pomocí ST monády není možné dělat vedlejší efekty, jenom v té kapse můžeme mít měnitelný stav pro efektivní zalgoritmizovaní nějakého problému. Z vnějšku je kapsa čistá, ve vnitřku nikoli.
-
Vytvořit lambdu která volá Cčkovskou funkci není čisté, a rozhodně o nic víc než zavolání té funkce rovnou. A runtimu se nic nepředává, runtime Haskellu nemá žádný modul pro IO. A i kdyby se předávalo, na faktu že v čistém jazyce píšeme kód s vedlejšími efekty se nic nezmění.
Ještě jednou: ve funkci main jenom vytvoříš datovou strukturu, která popisuje nějaký sled akcí. Pokud generování datové struktury "není čisté", tak už fakt nevím, co by mělo být čisté...
Čistotu IO monády jsem začal zpochybňovat od té doby, co jsem ji začal používat i k něčemu složitějšímu než čtení a zapisování do konzole. Ačkoli, já jsem ji nezačal zpochybňovat, já jsem se snažil zoufale pochopit jak to může být funkcionální. Řešení je prosté, není. A rozepsání nic nemění. Po rozepsání to sice nebude vypadat jak kód v Cčku, ale chovat se bude stejně.
Ale jistěže to je funkcionální, v tom nejstriktnějším možném slova smyslu. Pokud tomu nevěříš, tak si to asi budeš muset nastudovat do hloubky včetně teorie kategorií, kde to uvidíš jasně a důkaz tam budeš mít rigorozní.
Pokud máš pocit, že "to funkcionální není", tak ty důvody rozepiš formálně: podej definici "funkcionální" a ukaž, který z bodů to podle tebe nesplňuje. Skoro bych řekl, že by ti mělo být předem jasné, že nemáš šanci uspět, protože za touhle celou strukturou jsou mozky, které fakt nedělají nějaké hloupé chyby...
-
Vytvořit lambdu která volá Cčkovskou funkci není čisté, a rozhodně o nic víc než zavolání té funkce rovnou. A runtimu se nic nepředává, runtime Haskellu nemá žádný modul pro IO. A i kdyby se předávalo, na faktu že v čistém jazyce píšeme kód s vedlejšími efekty se nic nezmění.
Ještě jednou: ve funkci main jenom vytvoříš datovou strukturu, která popisuje nějaký sled akcí. Pokud generování datové struktury "není čisté", tak už fakt nevím, co by mělo být čisté...
Čistotu IO monády jsem začal zpochybňovat od té doby, co jsem ji začal používat i k něčemu složitějšímu než čtení a zapisování do konzole. Ačkoli, já jsem ji nezačal zpochybňovat, já jsem se snažil zoufale pochopit jak to může být funkcionální. Řešení je prosté, není. A rozepsání nic nemění. Po rozepsání to sice nebude vypadat jak kód v Cčku, ale chovat se bude stejně.
Ale jistěže to je funkcionální, v tom nejstriktnějším možném slova smyslu. Pokud tomu nevěříš, tak si to asi budeš muset nastudovat do hloubky včetně teorie kategorií, kde to uvidíš jasně a důkaz tam budeš mít rigorozní.
Pokud máš pocit, že "to funkcionální není", tak ty důvody rozepiš formálně: podej definici "funkcionální" a ukaž, který z bodů to podle tebe nesplňuje. Skoro bych řekl, že by ti mělo být předem jasné, že nemáš šanci uspět, protože za touhle celou strukturou jsou mozky, které fakt nedělají nějaké hloupé chyby...
Ano, vytvoří se neměnná datová struktura, v které jsou lambdy s vedlejšími efekty. A když se tato struktura poté vyhodnocuje, začnou se vedlejší efekty projevovat. Mám dvě otázky. Pokud je IO monáda čistá, lze udělat následující strukturu kódu
-----------------------------------------------
IO
-----------------------------------------------
Bez IO monády
-----------------------------------------------
IO
-----------------------------------------------
ale v Haskellu to nejde. Neexisuje něco jako runIO protože runIO nelze nahradit svým výstupem. A druhá otázka, pokud je IO monáda čistá, proč ji nemůžeme zparalelizovat pomocí par? Neměl by to být problém ne? Ale v Haskellu to nejde. Par ignoruje IO monádu.
Třeba u STRef je možnost zavolat runST, a tím umístit ST monádu i do čistého kódu, ST monáda je ale navenek čistá, neumožňuje vedlejší efekty, takže výstup je deterministický ačkoli ve vnitřku ST monáda čistá není.
-
Pokud je IO monáda čistá, lze udělat následující strukturu kódu
Sorry, ale tomu zápisu nerozumím, nevím, co jsou ty čáry atd. Nešlo by ukázat normální kód, který se v Haskellu nepřeloží?
Neexisuje něco jako runIO protože runIO nelze nahradit svým výstupem.
Tady se už dostávám na tenkej led, takže opět doufám, že to někdo případně opraví: nejde to právě proto, že ty potřebuješ IO vzít a vrátit ho runtimu jako návrat funkce main. V jazyku samotném prostě tu datovou strukturu popisující IO nemůžeš spustit. To je přesně ta moje pointa.
Můžeš tu monádu předávat celým program a vyplivnout ji do main, ale nemůžeš se jí uprostřed programu "zbavit" = "spustit ji" - a to právě proto, že kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je.
A druhá otázka, pokud je IO monáda čistá, proč ji nemůžeme zparalelizovat pomocí par? Neměl by to být problém ne? Ale v Haskellu to nejde. Par ignoruje IO monádu.
Tohle už je na mě moc implementačně-specifická otázka, do té se raději pouštět nebudu, nejsem praktický haskeller.
-
Ano, vytvoří se neměnná datová struktura, v které jsou lambdy s vedlejšími efekty. A když se tato struktura poté vyhodnocuje, začnou se vedlejší efekty projevovat.
Vyhodnocení výrazu typu IO a do slabé hlavní normální formy žádné vedlejší efekty neprovede - můžete si ověřit pomocí seq.
A druhá otázka, pokud je IO monáda čistá, proč ji nemůžeme zparalelizovat pomocí par?
Proč byste nemohl? Můžete klidně napsat putStrLn "a" `par` 3. Samozřejmě, žádný vedlejší efekt se neprovede, protože putStrLn "a"
žádný vedlejší efekt nedělá.
-
Ano, vytvoří se neměnná datová struktura, v které jsou lambdy s vedlejšími efekty. A když se tato struktura poté vyhodnocuje, začnou se vedlejší efekty projevovat.
Vyhodnocení výrazu typu IO a do slabé hlavní normální formy žádné vedlejší efekty neprovede - můžete si ověřit pomocí seq.
Mně pro pochopení pomohlo hlavně vykuchání IO a. Ona je to maskovaná funkce World -> (a, World) i když možná je to teď implementované nějak jinak. 'bind' propojí tyhle bloky tak, že svět z jednoho pošle do dalšího. To samé se děje i u State a ST monádů. Veškerý stav, co se tam modifikuje se předává jako parametr a vrací jeho nová verze. Jediný rozdíl mezi IO a všemi ostatními je v tom, že v IO se "předává" stav celého světa.
Spíš než na IO a všechno ostatní si to teď dělím na přiměřené a obludné koule stavu. A některé příklady na FRP v Elmu bych za ty obludné koule stavu teda považoval.
A druhá otázka, pokud je IO monáda čistá, proč ji nemůžeme zparalelizovat pomocí par?
Proč byste nemohl? Můžete klidně napsat putStrLn "a" `par` 3. Samozřejmě, žádný vedlejší efekt se neprovede, protože putStrLn "a"
žádný vedlejší efekt nedělá.
Ona se totiž ta funkce World->... začne vyhodnocovat až ta jedna veliká poskládaná lambda vypadne z mainu a runtime do ní strčí ten World. Pak se začnou odbalovat jednotlivé vrstvy. Ale nikde se to nevětví, jen se ty lambdy loupou jak cibule. Nikde tam není nějaký rozumný podstrom který by stálo za to označit a vyhodnotit bokem. Ty rozumné podstromy se objevují až mimo IO kód.
-
Mně pro pochopení pomohlo hlavně vykuchání IO a.
Mně pomohly tyhle slajdy: http://www.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt - od slajdu 136. Analogie s kolejemi je báječně srozumitelná.
Ona je to maskovaná funkce World -> (a, World) i když možná je to teď implementované nějak jinak.
On se tam ale žádný "world" skutečně nepředává, ne? Měl jsem za to, že to je jenom z důvodu typového odlišení, jakobych udělal třeba a -> [a] a tím dostal nový typ, který mi vynutí to správné poskládání fcí za sebe.
-
Mirek Prýmek :
Podle https://wiki.haskell.org/IO_inside je tam fake typ RealWorld, který ale překladač nakonec vyhodí protože odpovídá (). Před časem jsem ho ve zdrojácích i našel, ale teď si nepamatuju přesně kde. Bude někde kolem ST monády, nebo bych aspoň začal hledat od stToIO.
-
Pokud je IO monáda čistá, lze udělat následující strukturu kódu
Sorry, ale tomu zápisu nerozumím, nevím, co jsou ty čáry atd. Nešlo by ukázat normální kód, který se v Haskellu nepřeloží?
Neexisuje něco jako runIO protože runIO nelze nahradit svým výstupem.
Tady se už dostávám na tenkej led, takže opět doufám, že to někdo případně opraví: nejde to právě proto, že ty potřebuješ IO vzít a vrátit ho runtimu jako návrat funkce main. V jazyku samotném prostě tu datovou strukturu popisující IO nemůžeš spustit. To je přesně ta moje pointa.
Můžeš tu monádu předávat celým program a vyplivnout ji do main, ale nemůžeš se jí uprostřed programu "zbavit" = "spustit ji" - a to právě proto, že kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je.
A druhá otázka, pokud je IO monáda čistá, proč ji nemůžeme zparalelizovat pomocí par? Neměl by to být problém ne? Ale v Haskellu to nejde. Par ignoruje IO monádu.
Tohle už je na mě moc implementačně-specifická otázka, do té se raději pouštět nebudu, nejsem praktický haskeller.
To mne připadá padlé na hlavu. Proti takové argumentaci nemám co říct. Přesně podobné řeči nováčky matou, a zmatou je tak, až radši funkcionální programování zahodí. Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
-
Ano, vytvoří se neměnná datová struktura, v které jsou lambdy s vedlejšími efekty. A když se tato struktura poté vyhodnocuje, začnou se vedlejší efekty projevovat.
Vyhodnocení výrazu typu IO a do slabé hlavní normální formy žádné vedlejší efekty neprovede - můžete si ověřit pomocí seq.
Mně pro pochopení pomohlo hlavně vykuchání IO a. Ona je to maskovaná funkce World -> (a, World) i když možná je to teď implementované nějak jinak. 'bind' propojí tyhle bloky tak, že svět z jednoho pošle do dalšího. To samé se děje i u State a ST monádů. Veškerý stav, co se tam modifikuje se předává jako parametr a vrací jeho nová verze. Jediný rozdíl mezi IO a všemi ostatními je v tom, že v IO se "předává" stav celého světa.
Spíš než na IO a všechno ostatní si to teď dělím na přiměřené a obludné koule stavu. A některé příklady na FRP v Elmu bych za ty obludné koule stavu teda považoval.
A druhá otázka, pokud je IO monáda čistá, proč ji nemůžeme zparalelizovat pomocí par?
Proč byste nemohl? Můžete klidně napsat putStrLn "a" `par` 3. Samozřejmě, žádný vedlejší efekt se neprovede, protože putStrLn "a"
žádný vedlejší efekt nedělá.
Ona se totiž ta funkce World->... začne vyhodnocovat až ta jedna veliká poskládaná lambda vypadne z mainu a runtime do ní strčí ten World. Pak se začnou odbalovat jednotlivé vrstvy. Ale nikde se to nevětví, jen se ty lambdy loupou jak cibule. Nikde tam není nějaký rozumný podstrom který by stálo za to označit a vyhodnotit bokem. Ty rozumné podstromy se objevují až mimo IO kód.
V Elmu žádná funkce nemá vedlejší efekty a ani nezná měnitelný stav. Vše jsou jenom dráhy signálů, na kterých sedí čisté funkce které je modifikují.
-
To mne připadá padlé na hlavu. Proti takové argumentaci nemám co říct. Přesně podobné řeči nováčky matou, a zmatou je tak, až radši funkcionální programování zahodí.
Tak teď ti teda vůbec nerozumím. Pouštíš se do silných tvrzení ("Haskell není čistý!") a když se snažím povídavě, ne-rigorozně ukázat, proč čistý je, tak se ti to nelíbí, že to nováčky mate... No tak pokud to nováčky mate, tak nemají vydávat silná prohlášení :) Vždyť pořád si jenom tak neformálně kloužeme po povrchu, nikdo tady ještě nezačal ani podávat nějaké důkazy vlastností funktorů nebo přirozených transformací ;)
Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
Ale vůbec ne. Platí tohle:
pokud je jazyk čistý -> musím IO nějak obchcat, třeba pomocí monád
NEplatí tohle:
pokud má jazyk monády -> je čistý
Čistota je vlastnost jazyka jako celku, s monádami to nemá co dělat, monády jsou jenom nástroj.
-
Mirek Prýmek :
Podle https://wiki.haskell.org/IO_inside je tam fake typ RealWorld, který ale překladač nakonec vyhodí protože odpovídá (). Před časem jsem ho ve zdrojácích i našel, ale teď si nepamatuju přesně kde. Bude někde kolem ST monády, nebo bych aspoň začal hledat od stToIO.
Jj, to je ono. Nepředává se tam world ve smyslu nějakých dat, ale jenom se záměrně vytváří nový typ.
-
V Elmu žádná funkce nemá vedlejší efekty a ani nezná měnitelný stav. Vše jsou jenom dráhy signálů, na kterých sedí čisté funkce které je modifikují.
A ten model v MVC je teda co?
-
Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
Na jakýkoliv jazyk to nasadit nejde - musel byste změnit definici toho jazyka.
Například jednoduchý jazyk, na nějž to nejde nasadit, je ML kalkulus (http://gallium.inria.fr/~fpottier/publis/emlti-final.pdf#7) - popis sémantiky na straně 395.
-
V Elmu žádná funkce nemá vedlejší efekty a ani nezná měnitelný stav. Vše jsou jenom dráhy signálů, na kterých sedí čisté funkce které je modifikují.
A ten model v MVC je teda co?
Neměnný. Na FRP je úžasné že můžeme mít globální stav, který se nemění. Stav je ve FRP uchován ve zpětných signálních vazbách. Neměnní se, pokaždé se vytvoří jeho modifikovaná kopie, a pošle se signálem dál.
-
Stav je ve FRP uchován ve zpětných signálních vazbách. Neměnní se, pokaždé se vytvoří jeho modifikovaná kopie, a pošle se signálem dál.
Což je přesně tentýž princip jako mají monády, máš to o asi tři příspěvky výš ;) Akorát teda samotné IO žádný stav nepřenáší, ale kdybys chtěl, můžeš si ho tam dát.
-
Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
Na jakýkoliv jazyk to nasadit nejde - musel byste změnit definici toho jazyka.
Například jednoduchý jazyk, na nějž to nejde nasadit, je ML kalkulus (http://gallium.inria.fr/~fpottier/publis/emlti-final.pdf#7) - popis sémantiky na straně 395.
Ale kdepak. Prostě C je čistě funkcionální, a jakákoli funkce která má vedlejší efekty je ve výsledku jen lambda, kterou interpretuje runtime. Všechno je krásně čisté. Ještě potřebujeme ty monády, aby to mělo všechny náležitosti.
-
Ale kdepak. Prostě C je čistě funkcionální, a jakákoli funkce která má vedlejší efekty je ve výsledku jen lambda, kterou interpretuje runtime. Všechno je krásně čisté. Ještě potřebujeme ty monády, aby to mělo všechny náležitosti.
C není čistý, protože když dvakrát po sobě zavolám random(), vrátí mi pokaždé jinou hodnotu. V Haskellu nic takového není možné a proto je čistý.
To, že "a <- get" VYPADÁ jako volání funkce, na tom nic nemění, protože to volání fce NENÍ.
-
Neexisuje něco jako runIO protože runIO nelze nahradit svým výstupem.
Můžeš tu monádu předávat celým program a vyplivnout ji do main, ale nemůžeš se jí uprostřed programu "zbavit" = "spustit ji" - a to právě proto, že kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je.
Tu logiku nechápu. Proč bych se nemohl monády zbavit? Maybe, nebo Either se zbavit lze. Jak vzniká souvislost, že: "kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je."? Naopak mě přijde, že díky tomu, že IOMonádu nelze substituovat, tak to znamená, že není čistá.
-
Tu logiku nechápu. Proč bych se nemohl monády zbavit? Maybe, nebo Either se zbavit lze. Jak vzniká souvislost, že: "kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je."? Naopak mě přijde, že díky tomu, že IOMonádu nelze substituovat, tak to znamená, že není čistá.
Pokud máš někde proměnnou "a" typu IO Num, tak nemůžeš provést něco jako "runIO a", dostat z ní ten integer a dál pokračovat čistě jenom s integerem. Vždycky musíš začít v IO monádě (main fce) - z ní můžeš tímpádem mít větve, které taky provádí IO. Nemůžeš ale IO větev naroubovat na ne-IO větev. Aspoň myslím teda ;)
-
IO Num
Vlastně Num by musel být constraint, ale tak rozumíme si že jo ;)
-
Stav je ve FRP uchován ve zpětných signálních vazbách. Neměnní se, pokaždé se vytvoří jeho modifikovaná kopie, a pošle se signálem dál.
Což je přesně tentýž princip jako mají monády, máš to o asi tři příspěvky výš ;) Akorát teda samotné IO žádný stav nepřenáší, ale kdybys chtěl, můžeš si ho tam dát.
Musím nesouhlasit. Vyzkoušel jste si FRP? Porovnávat IO monádu a FRP je silně podivné i pro začátečníka jako jsem já. FRP nezná měnitelný stav. Není tam nikde, stejně jako vedlejší efekty, a podle toho vypadá a chová se i kód. Neexistuje tam nic jako měnitelná reference, a ani něco takového není třeba. IO monáda a FRP je něco naprosto kategoricky odlišného. Toto už je za hranicí, to už cítím jako demagogie.
-
Tu logiku nechápu. Proč bych se nemohl monády zbavit? Maybe, nebo Either se zbavit lze. Jak vzniká souvislost, že: "kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je."? Naopak mě přijde, že díky tomu, že IOMonádu nelze substituovat, tak to znamená, že není čistá.
Pokud máš někde proměnnou "a" typu IO Num, tak nemůžeš provést něco jako "runIO a", dostat z ní ten integer a dál pokračovat čistě jenom s integerem. Vždycky musíš začít v IO monádě (main fce) - z ní můžeš tímpádem mít větve, které taky provádí IO. Nemůžeš ale IO větev naroubovat na ne-IO větev. Aspoň myslím teda ;)
O tom jsem mluvil. Není to možné prostě proto, že IO není deterministické, neboli čisté.
-
Ale kdepak. Prostě C je čistě funkcionální, a jakákoli funkce která má vedlejší efekty je ve výsledku jen lambda, kterou interpretuje runtime. Všechno je krásně čisté. Ještě potřebujeme ty monády, aby to mělo všechny náležitosti.
C není čistý, protože když dvakrát po sobě zavolám random(), vrátí mi pokaždé jinou hodnotu. V Haskellu nic takového není možné a proto je čistý.
To, že "a <- get" VYPADÁ jako volání funkce, na tom nic nemění, protože to volání fce NENÍ.
Ale je
random :: IO Int
random = ...
úplně to samé. A teď budeme tvrdit, že v Cčku random() vrátí jen lambdu kterou interpretuje runtime.
-
Tu logiku nechápu. Proč bych se nemohl monády zbavit? Maybe, nebo Either se zbavit lze. Jak vzniká souvislost, že: "kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je."? Naopak mě přijde, že díky tomu, že IOMonádu nelze substituovat, tak to znamená, že není čistá.
Pokud máš někde proměnnou "a" typu IO Num, tak nemůžeš provést něco jako "runIO a", dostat z ní ten integer a dál pokračovat čistě jenom s integerem. Vždycky musíš začít v IO monádě (main fce) - z ní můžeš tímpádem mít větve, které taky provádí IO. Nemůžeš ale IO větev naroubovat na ne-IO větev. Aspoň myslím teda ;)
Proč musím? Proč je to tak správně? A proč to znamená, že když by to bylo možné, tak by Haskell čistý nebyl?
unpackMonad :: Maybe Int -> Int
unpackMonad Nothing = 0
unpackMonad Maybe i = i
-
Musím nesouhlasit. Vyzkoušel jste si FRP? Porovnávat IO monádu a FRP je silně podivné i pro začátečníka jako jsem já. FRP nezná měnitelný stav. Není tam nikde, stejně jako vedlejší efekty, a podle toho vypadá a chová se i kód. Neexistuje tam nic jako měnitelná reference, a ani něco takového není třeba. IO monáda a FRP je něco naprosto kategoricky odlišného. Toto už je za hranicí, to už cítím jako demagogie.
Ale monáda taky nic nemění, ani IO monáda. Říkám, máš to o pár příspěvků výš:
"Ona je to maskovaná funkce World -> (a, World)"
- vidíš to? Vezmu svět, aplikuju na něj něco, mám nový svět. Na nový svět opět aplikuju něco atd. Pořád ti to nepřijde podobné streamům? Neříkám, že je to totéž, ale ten způsob je velmi podobný. Akorátže u monád to máš celé zabalené do syntaktického cukru, aby to vypadalo rádobyimperativně.
O tom jsem mluvil. Není to možné prostě proto, že IO není deterministické, neboli čisté.
Ne. Není to možné přesně z opačného důvodu, kdyby taková funkce existovala, tak potom by to čisté nebylo. Teď to čisté je.
Ale je
random :: IO Int
random = ...
úplně to samé. A teď budeme tvrdit, že v Cčku random() vrátí jen lambdu kterou interpretuje runtime.
Není ani trochu. Protože IO Int není Int. Z IO Int nikdy Int nedostaneš, což je přesně to, co ti říkám výš.
Proč musím? Proč je to tak správně? A proč to znamená, že když by to bylo možné, tak by Haskell čistý nebyl?
unpackMonad :: Maybe Int -> Int
unpackMonad Nothing = 0
unpackMonad Maybe i = i
No protože pokud by tohle šlo udělat s IO monádou, tak bys právě dostal různé hodnoty pro různá volání funkce, a to prostě nesmíš dostat :)
U Maybe to nevadí, protože tam je předem jasné, co uvnitř je, a nemůže to být chvilku takhle a chvilku jinak.
-
Ne. Není to možné přesně z opačného důvodu, kdyby taková funkce existovala, tak potom by to čisté nebylo. Teď to čisté je.
Kuc, kuc...
Proč musím? Proč je to tak správně? A proč to znamená, že když by to bylo možné, tak by Haskell čistý nebyl?
unpackMonad :: Maybe Int -> Int
unpackMonad Nothing = 0
unpackMonad Maybe i = i
No protože pokud by tohle šlo udělat s IO monádou, tak bys právě dostal různé hodnoty pro různá volání funkce, a to prostě nesmíš dostat :)
To už je lepší.
Jenže stále to neřeší ten problém. Stavím na tom, že substituce výrazů je podmínka pro označení jazyka za (pure) funkcionální. Tím, že jsi to zakázal befelem, jsi tu substituci neumožnil.
-
Musím nesouhlasit. Vyzkoušel jste si FRP? Porovnávat IO monádu a FRP je silně podivné i pro začátečníka jako jsem já. FRP nezná měnitelný stav. Není tam nikde, stejně jako vedlejší efekty, a podle toho vypadá a chová se i kód. Neexistuje tam nic jako měnitelná reference, a ani něco takového není třeba. IO monáda a FRP je něco naprosto kategoricky odlišného. Toto už je za hranicí, to už cítím jako demagogie.
Ale monáda taky nic nemění, ani IO monáda. Říkám, máš to o pár příspěvků výš:
"Ona je to maskovaná funkce World -> (a, World)"
- vidíš to? Vezmu svět, aplikuju na něj něco, mám nový svět. Na nový svět opět aplikuju něco atd. Pořád ti to nepřijde podobné streamům? Neříkám, že je to totéž, ale ten způsob je velmi podobný. Akorátže u monád to máš celé zabalené do syntaktického cukru, aby to vypadalo rádobyimperativně.
O tom jsem mluvil. Není to možné prostě proto, že IO není deterministické, neboli čisté.
Ne. Není to možné přesně z opačného důvodu, kdyby taková funkce existovala, tak potom by to čisté nebylo. Teď to čisté je.
Ale je
random :: IO Int
random = ...
úplně to samé. A teď budeme tvrdit, že v Cčku random() vrátí jen lambdu kterou interpretuje runtime.
Není ani trochu. Protože IO Int není Int. Z IO Int nikdy Int nedostaneš, což je přesně to, co ti říkám výš.
Proč musím? Proč je to tak správně? A proč to znamená, že když by to bylo možné, tak by Haskell čistý nebyl?
unpackMonad :: Maybe Int -> Int
unpackMonad Nothing = 0
unpackMonad Maybe i = i
No protože pokud by tohle šlo udělat s IO monádou, tak bys právě dostal různé hodnoty pro různá volání funkce, a to prostě nesmíš dostat :)
U Maybe to nevadí, protože tam je předem jasné, co uvnitř je, a nemůže to být chvilku takhle a chvilku jinak.
Takže, chci vysvětlení jak to že je možné v Haskellu 1:1 namapovat kód v Cčku i se všemi měnitelnými proměnnými a funkcemi do IO monády a tento kód se chová stejně jako kód v Cčku. Pokud trváte na tom že je to čistý kód, pak i samotné Cčko je čisté, stačí mu skutečně jen přidat ty monády a tvrdit to samé co u Haskellu.
-
Jenže stále to neřeší ten problém. Stavím na tom, že substituce výrazů je podmínka pro označení jazyka za (pure) funkcionální. Tím, že jsi to zakázal befelem, jsi tu substituci neumožnil.
Říkám, že v čistém jazyce nemůžeš při dvou volání stejné fce se stejnými argumenty dostat něco jiného. Pokud by runIO existovalo, tak prostě uděláš dvakrát po sobě "runIO a" a pokaždé dostaneš něco jiného. Takže:
jazyk je čistý -> v jazyce nemůže existovat runIO
...ne naopak!
-
Jenže stále to neřeší ten problém. Stavím na tom, že substituce výrazů je podmínka pro označení jazyka za (pure) funkcionální. Tím, že jsi to zakázal befelem, jsi tu substituci neumožnil.
Říkám, že v čistém jazyce nemůžeš při dvou volání stejné fce se stejnými argumenty dostat něco jiného. Pokud by runIO existovalo, tak prostě uděláš dvakrát po sobě "runIO a" a pokaždé dostaneš něco jiného. Takže:
jazyk je čistý -> v jazyce nemůže existovat runIO
...ne naopak!
A proč by vrátilo runIO něco jiného při opakovaném volání. IO monáda je přece čistá.
-
Takže, chci vysvětlení jak to že je možné v Haskellu 1:1 namapovat kód v Cčku i se všemi měnitelnými proměnnými a funkcemi do IO monády a tento kód se chová stejně jako kód v Cčku. Pokud trváte na tom že je to čistý kód, pak i samotné Cčko je čisté, stačí mu skutečně jen přidat ty monády a tvrdit to samé co u Haskellu.
Není to možné a ten kód se NECHOVÁ stejně.
Kód A:
int a = random();
int b = random();
(pseudo)kód B:
a <- random
b <- random
To, že A a B vypadá na pohled stejně, vůbec nic neznamená. Význam toho kódu je úplně jiný. Ten první kód dvakrát volá tutéž fci, ten druhý kód ve skutečnosti vytváří jakési lambdy, ty jaksi skládá za sebe pomocí jakéhosi fakového RealWorld.
V Haskellu prostě platí, že když dvakrát zavolám tutéž ***FUNKCI*** dvakrát, vrátí mi vždy to samé. "a <- random" ***NENí*** volání funkce. I kdyby tak ta syntaxe klidně stokrát vypadala. Není. Není a není. Tečka.
:)))
-
A proč by vrátilo runIO něco jiného při opakovaném volání. IO monáda je přece čistá.
Definuj "IO monáda je čistá". Striktně a přesně.
-
A proč by vrátilo runIO něco jiného při opakovaném volání. IO monáda je přece čistá.
Definuj "IO monáda je čistá". Striktně a přesně.
Referenčně transparentní.
-
Jenže stále to neřeší ten problém. Stavím na tom, že substituce výrazů je podmínka pro označení jazyka za (pure) funkcionální. Tím, že jsi to zakázal befelem, jsi tu substituci neumožnil.
Říkám, že v čistém jazyce nemůžeš při dvou volání stejné fce se stejnými argumenty dostat něco jiného. Pokud by runIO existovalo, tak prostě uděláš dvakrát po sobě "runIO a" a pokaždé dostaneš něco jiného. Takže:
jazyk je čistý -> v jazyce nemůže existovat runIO
...ne naopak!
O runIO nejde. Jde o to, že nejde udělat substituci výrazu.
Jazyk je čistý, pokud mohu, mimo jiné, provádět nahrazení výrazu její hodnotou - alespoň takhle jsem to vždycky četl. O runIO tam nic nebylo :-)
Když budu mět kdekoliv v kódu číslo, tak ho mohu bezezbytku přetavit na Maybe monádu. A naopak. Zatímco když budu mět to samé v IOMonádě, tak se jí, jako jediné, nezbavím. A při všech transformacích ji tam budu tahat jak vocásek. To znamená, že ta substituce se provede - ale s ocáskem. A možná proto bych ji za čistou neprohlásil.
-
Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
Na jakýkoliv jazyk to nasadit nejde - musel byste změnit definici toho jazyka.
Například jednoduchý jazyk, na nějž to nejde nasadit, je ML kalkulus (http://gallium.inria.fr/~fpottier/publis/emlti-final.pdf#7) - popis sémantiky na straně 395.
Ale kdepak. Prostě C je čistě funkcionální, a jakákoli funkce která má vedlejší efekty je ve výsledku jen lambda, kterou interpretuje runtime. Všechno je krásně čisté. Ještě potřebujeme ty monády, aby to mělo všechny náležitosti.
C takhle není definováno (bohužel C není formálně definováno - proto jsem dal jako příklad ML kalkulus).
-
Takže, chci vysvětlení jak to že je možné v Haskellu 1:1 namapovat kód v Cčku i se všemi měnitelnými proměnnými a funkcemi do IO monády a tento kód se chová stejně jako kód v Cčku. Pokud trváte na tom že je to čistý kód, pak i samotné Cčko je čisté, stačí mu skutečně jen přidat ty monády a tvrdit to samé co u Haskellu.
Není to možné a ten kód se NECHOVÁ stejně.
Kód A:
int a = random();
int b = random();
(pseudo)kód B:
a <- random
b <- random
To, že A a B vypadá na pohled stejně, vůbec nic neznamená. Význam toho kódu je úplně jiný. Ten první kód dvakrát volá tutéž fci, ten druhý kód ve skutečnosti vytváří jakési lambdy, ty jaksi skládá za sebe pomocí jakéhosi fakového RealWorld.
V Haskellu prostě platí, že když dvakrát zavolám tutéž ***FUNKCI*** dvakrát, vrátí mi vždy to samé. "a <- random" ***NENí*** volání funkce. I kdyby tak ta syntaxe klidně stokrát vypadala. Není. Není a není. Tečka.
:)))
Překvapivě se chová stejně. GTK2hs je přesně 1:1 namapovaná knihovna. Pokud ji používám, kód má strukturu stejnou jako v Cčku, a stejně se i chová. Opět opakuji, stačí přidat do Cčka monády, IO strčit do lamdb, a máme pure C. Nebo alespoň pure C z Vašeho pohledu.
-
Referenčně transparentní.
Co je referenčně transparentní? Referenčně transparentní může být jenom JAZYK.
Typ "IO Int" je prostě datový typ. Proměnná "a" typu "IO Int" jsou prostě nějaká DATA. Představ si to tak, že ta data je string s instrukcemi pro IO, třeba: "Načti další byte ze souboru f". Pokud bys měl funkci runIO, tak ji zavoláš poprvé:
runIO a = runIO "Načti další byte ze souboru f" = Byte1
...a podruhé:
runIO a = runIO "Načti další byte ze souboru f" = Byte2
Totéž volání fce "runIO" s týmž argumentem "a" ti dalo různý výsledek. A to se v čistém jazyce nesmí stát. Proto runIO v Haskellu nemůže existovat.
-
Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
Na jakýkoliv jazyk to nasadit nejde - musel byste změnit definici toho jazyka.
Například jednoduchý jazyk, na nějž to nejde nasadit, je ML kalkulus (http://gallium.inria.fr/~fpottier/publis/emlti-final.pdf#7) - popis sémantiky na straně 395.
Ale kdepak. Prostě C je čistě funkcionální, a jakákoli funkce která má vedlejší efekty je ve výsledku jen lambda, kterou interpretuje runtime. Všechno je krásně čisté. Ještě potřebujeme ty monády, aby to mělo všechny náležitosti.
C takhle není definováno (bohužel C není formálně definováno - proto jsem dal jako příklad ML kalkulus).
Tak ho tak prostě definujeme, stačí jenom přidat IO monádu, a máme pure C. Nebo si můžeme udělat nový jazyk PureC s vlastní definicí se základem v Cčku. Nejlepší na tom je, že nebudeme muset psát jiný kompiler. Je to jen hra se slovy.
-
O runIO nejde. Jde o to, že nejde udělat substituci výrazu.
Reagoval jsi na příspěvek, ve kterém jsem říkal, proč runIO v Haskellu nemůže existovat. Proto o něm mluvím.
Jazyk je čistý, pokud mohu, mimo jiné, provádět nahrazení výrazu její hodnotou
Souhlas. Ekvivalentně: pokud každé volání stejné funkce se stejnými parametry dá tentýž výsledek.
Když budu mět kdekoliv v kódu číslo, tak ho mohu bezezbytku přetavit na Maybe monádu. A naopak. Zatímco když budu mět to samé v IOMonádě, tak se jí, jako jediné, nezbavím. A při všech transformacích ji tam budu tahat jak vocásek. To znamená, že ta substituce se provede - ale s ocáskem. A možná proto bych ji za čistou neprohlásil.
Já pořád nějak nechápu, kde vidíš problém. Pokud fce vrací IO Int, tak prostě vrací nějaká data. Pokaždé stejná pro stejné argumenty. A přesně tak to má být. Kde je problém?
-
Tak ho tak prostě definujeme, stačí jenom přidat IO monádu, a máme pure C. Nebo si můžeme udělat nový jazyk PureC s vlastní definicí se základem v Cčku. Nejlepší na tom je, že nebudeme muset psát jiný kompiler. Je to jen hra se slovy.
Věta "přidáme tam monádu a máme pure X" je stejně nesmyslná jako "přidáme tam <cokoli jinýho> a máme pure X". Purity není dáno tím, jestli jazyk má nebo nemá monády. Monády jsou NÁSTROJ, jak V ČISTÉM JAZYCE něco udělat. V nečistém jazyce tento nástroj
1. nepotřebuješ
2. z nečistého jazyka ti čistý neudělá
Vždyť se všichni shodujeme na definici "v čistém jazyce dvě volání vždy dávají stejný výsledek". Tak jestli chceš dokazovat, že Haskell není čistý, tak ukaž, jaké dvě fce můžou dát se stejnými argumenty jiný výsledek a je to, ne? Proč se babrat v čemkoli jiným, ne?
-
Když budu mět kdekoliv v kódu číslo, tak ho mohu bezezbytku přetavit na Maybe monádu. A naopak. Zatímco když budu mět to samé v IOMonádě, tak se jí, jako jediné, nezbavím. A při všech transformacích ji tam budu tahat jak vocásek. To znamená, že ta substituce se provede - ale s ocáskem. A možná proto bych ji za čistou neprohlásil.
Já pořád nějak nechápu, kde vidíš problém. Pokud fce vrací IO Int, tak prostě vrací nějaká data. Pokaždé stejná pro stejné argumenty. A přesně tak to má být. Kde je problém?
Myslím, že už tě chápu.
-
Vaše argumenty lze po mírné modifikaci nasadit na jakýkoli jazyk, a poté tvrdit že je čistý. Stačí jen vytvořit monády. což není problém.
Na jakýkoliv jazyk to nasadit nejde - musel byste změnit definici toho jazyka.
Například jednoduchý jazyk, na nějž to nejde nasadit, je ML kalkulus (http://gallium.inria.fr/~fpottier/publis/emlti-final.pdf#7) - popis sémantiky na straně 395.
Ale kdepak. Prostě C je čistě funkcionální, a jakákoli funkce která má vedlejší efekty je ve výsledku jen lambda, kterou interpretuje runtime. Všechno je krásně čisté. Ještě potřebujeme ty monády, aby to mělo všechny náležitosti.
C takhle není definováno (bohužel C není formálně definováno - proto jsem dal jako příklad ML kalkulus).
Tak ho tak prostě definujeme, stačí jenom přidat IO monádu, a máme pure C. Nebo si můžeme udělat nový jazyk PureC s vlastní definicí se základem v Cčku. Nejlepší na tom je, že nebudeme muset psát jiný kompiler.
Nestačí jenom přidat IO monádu. Musíte minimálně odebrat nebo omezit něco, čemu se v tom ML kalkulu říká "store" - například byste musel přístup do "storu" provádět pouze z IO monády.
Je to jen hra se slovy.
Není to jen hra se slovy. Má to praktické důsledky: Například optimalizace/transformace, jenž může kompilátor provádět, nebo omezení na korektní typový systém (v čistém jazyce například nepotřebujete value restriction).
-
Myslím, že už tě chápu.
Ono by se to asi dalo říct i tak, že požaduješ nějakou vlastnost, která ale z definice nevyplývá. Nemusíme jít do monády, stačí nám funktor, ten je definovanej takhle:
class Functor (f :: * -> *) where
fmap :: (a -> b) -> f a -> f b
- tam nikde nemáš řečený, že musí existovat způsob, jak můžeš z toho "boxu" tu hodnotu vytáhnout. To udělá implementace fmap pro konkrétní functor za tebe a opět ti vrátí jenom box, do kterýho se podívat nemůžeš, protože jeho strukturu obecně nemusíš znát. To, že ji u Maybe znáš a tímpádem můžeš tu hodnotu vytáhnout pattern matchingem je nějaká informace navíc, kterou obecně definice Functoru nezaručuje.
...a dá se to říct i ještě abstraktněji: functor nemusí být ani žádný "box na hodnoty", je to prostě endofunctor ;) https://en.wikipedia.org/wiki/Functor
-
...a dá se to říct i ještě abstraktněji: functor nemusí být ani žádný "box na hodnoty", je to prostě endofunctor ;)
...teď jsem teda mocně zavařoval závity a přemýšlel nad tím, jestli by v Haskellu mohl být i nějaký ne-box functor a nic mě nenapadlo, kromě identity, což je vlastně takový null-box. Takže to asi nebyl úplně dobrý příklad :))
Ale kdybys měl možnost introspekce obecné funkce a mohl nějak přiohnout ji, místo té vstupní a výstupní hodnoty... Možná by to nějak i šlo. Ale asi teda spíš ne :))
-
Identita je funkce. O funkcí nemůžu říct, že je functor, to řeknu o typu. Nevím, co si představuješ pod ne-box functorem, ale nemohla by to být třeba funkce?
instance Functor ((->) r) where
fmap f g = (\x -> f (g x))
-
Identita je funkce. O funkcí nemůžu říct, že je functor, to řeknu o typu.
Přesněji o typovém konstruktoru s kindem (jak se to řekně česky?) * -> * :)
Myslel jsem to tak, že by fmap byl identita, jenže to vlastně v Haskellu taky nejde, to je pech :)
Nevím, co si představuješ pod ne-box functorem, ale nemohla by to být třeba funkce?
instance Functor ((->) r) where
fmap f g = (\x -> f (g x))
Jo, to by asi mohla :) Hlavně že jsem se na tu kapitolu v LYAH, kde je přesně tohle, před chvilkou ještě koukal :)) Dík!
-
To závisí od toho, či nám tá Cantorova alebo Riemannova funkcia naozaj pripadá divná alebo nie. Ako ukazuje diskusia v tomto vlákne (ale aj na iných fórach), tak čistota Haskellu jednoznačne mnohým ľuďom divná pripadá. Čím, pravdaže, nevylučujem, že niekomu by nemusel pripadať divný ani funkcionálne čistý jazyk "obsahujúci C-čko".
Nebylo by lepší opustit ty mlhavé analogie a napsat to polopaticky? V čem Haskell není čistý? Zatím jsme narazili jenom na to, že forknutí IO je nečisté (což je jasný z principu). Něco dál?
To je skôr otázka pre tých, ktorí tvrdia, že nie je čistý. (O tom, že čistota Haskellu mnohým ľuďom skutočne divná pripadá, ťa snáď presvedčili príspevky z posledných stránok diskusie.)
A v jakém smyslu by měl být čistý "funkcionální jazyk obsahující céčko"?
V zmysle definície čistoty funkcionálneho jazyka.
Jak by měl vypadat?
Na spôsob vyššie spomínaného C/FPP. (Som si vedomý toho, že časť za lomítkom nebola presne špecifikovaná.)
V čem by se od Haskellu lišil?
V princípe by na mieste funkcionálneho predprocesora FPP mohol byť pokojne Haskell, ale účelu príkladu ďaleko lepšie poslúži čo najmenší (a najnepoužiteľnejší) čistý funkcionálny jazyk. Mne tam pre ilustráciu myšlienky vcelku postačoval aj spomínaný CPP, ale tebe vadilo, že nie je turingovsky úplný, preto som vyššie spomenul to doplnenie o SK-kalkulus.
-
Na spôsob vyššie spomínaného C/FPP. (Som si vedomý toho, že časť za lomítkom nebola presne špecifikovaná.)
Ok, takže máme nějaký čistý funkcionální jazyk, jehož jediným možným výstupem je text - konkrétně syntakticky správný C zdroják. A dál? Co s tím?
-
Na spôsob vyššie spomínaného C/FPP. (Som si vedomý toho, že časť za lomítkom nebola presne špecifikovaná.)
Ok, takže máme nějaký čistý funkcionální jazyk, jehož jediným možným výstupem je text - konkrétně syntakticky správný C zdroják. A dál? Co s tím?
Tento zdroják (presnejšie by sme mali povedať: dátová štruktúra jazyka C/FPP) je potom spracovaný v runtime systéme, ktorý môže byť z dôvodov efektívnosti realizovaný prekladom do strojového kódu.
Ináč som si nie istý, či som ťa správne pochopil: tým čistým funkcionálnym jazykom nazývaš len FPP alebo C/FPP?
-
Věta "přidáme tam monádu a máme pure X" je stejně nesmyslná jako "přidáme tam <cokoli jinýho> a máme pure X". Purity není dáno tím, jestli jazyk má nebo nemá monády. Monády jsou NÁSTROJ, jak V ČISTÉM JAZYCE něco udělat. V nečistém jazyce tento nástroj
1. nepotřebuješ
Ale hodí se. Momentálně se to na mailinglistu k boostu (C++ knihovny) monádama jenom hemží. A ta diskuze se netočí kolem užitečnosti. Diskutuje se hlavně, jak je nalakovat, aby se z nich "normální" C++ programátoři na místě nepodělali.
Ono C++ teď z funkcionálních jazyků bere překvapivě hodně. Furt je to hybrid, ale s std::function a funkčními objekty se dají dělat zajímavé věci.
-
Ale hodí se. Momentálně se to na mailinglistu k boostu (C++ knihovny) monádama jenom hemží. A ta diskuze se netočí kolem užitečnosti. Diskutuje se hlavně, jak je nalakovat, aby se z nich "normální" C++ programátoři na místě nepodělali.
Takže mám nečistý imperativní jazyk, do něho si dám čistou monádu a do monády si dám nečistý imperativní kód ? Jako kratochvíle na nedělní odpoledne dobré ;D
-
Ale hodí se. Momentálně se to na mailinglistu k boostu (C++ knihovny) monádama jenom hemží. A ta diskuze se netočí kolem užitečnosti. Diskutuje se hlavně, jak je nalakovat, aby se z nich "normální" C++ programátoři na místě nepodělali.
Takže mám nečistý imperativní jazyk, do něho si dám čistou monádu a do monády si dám nečistý imperativní kód ? Jako kratochvíle na nedělní odpoledne dobré ;D
Hodí se to například na modelování efektů, které v tom jazyce nejsou. Například vymezených kontinuací.
-
Ale hodí se. Momentálně se to na mailinglistu k boostu (C++ knihovny) monádama jenom hemží. A ta diskuze se netočí kolem užitečnosti. Diskutuje se hlavně, jak je nalakovat, aby se z nich "normální" C++ programátoři na místě nepodělali.
Takže mám nečistý imperativní jazyk, do něho si dám čistou monádu a do monády si dám nečistý imperativní kód ? Jako kratochvíle na nedělní odpoledne dobré ;D
Také tím můžete zajistit, aby vám nepřetekl zásobník.
-
Takže mám nečistý imperativní jazyk, do něho si dám čistou monádu a do monády si dám nečistý imperativní kód ? Jako kratochvíle na nedělní odpoledne dobré ;D
Monáda je matematická struktura. Není čistá ani nečistá. Čistota je vlastnost jazyka.
Jedno z využití monád je skládání IO operací za sebe v čistých jazycích. Další využití je třeba skládání řetězcových operací, skládání operací co můžou selhat, přidání nějakého kontextu a podobně. Monáda je všudypřítomný vzor a zjednodušovat ho na IO objekt je zásadní chyba.
-
Hodí se to například na modelování efektů, které v tom jazyce nejsou. Například vymezených kontinuací.
Jo, skládání asynchronních operací momentálně vypadá jako killer app. Aspoň teda v C++.
-
Tento zdroják (presnejšie by sme mali povedať: dátová štruktúra jazyka C/FPP) je potom spracovaný v runtime systéme, ktorý môže byť z dôvodov efektívnosti realizovaný prekladom do strojového kódu.
Dobře, ale nerozumím romu, co se snažíš říct, kam se chceš dobrat.
Ináč som si nie istý, či som ťa správne pochopil: tým čistým funkcionálnym jazykom nazývaš len FPP alebo C/FPP?
FPP je čistý, to jsme si dali do definice. FPP produkuje string, který se dá interpretovat jako zdroják v C, což čistý jazyk není.
Nevím, jakou tam hledáš záludnost. Říkal jsem to proto, že stejným způsobem runtime Haskellu interpretuje ty IO instrukce, což je taky jenom nějaká datová struktura (jako ten string) a úplně stejným způsobem z toho NEplyne, že Haskell není čistý jazyk.
-
Ale hodí se.
Jasan. Myslel jsem, že ho nepotřebuješ pro normální IO.
-
Hodí se to například na modelování efektů, které v tom jazyce nejsou.
Modelování budiž.
Také tím můžete zajistit, aby vám nepřetekl zásobník.
To žijete ve velkém omylu. Počáteční velikost zásobníku se dá volně měnit takže nevíte jak je velký a nikdy nevíte co tam kdo nasyslil před Vámi, neexistuje žádná obrana před tím proč by zrovna ve Vašem kódu nemohlo nastat přetečení zásobníku. Zrovna v C/C++ se často ještě před prvním řádkem uživatelského kódu alokuje na zásobníku.
Jedno z využití monád je skládání IO operací za sebe v čistých jazycích. Další využití je třeba skládání řetězcových operací, skládání operací co můžou selhat, přidání nějakého kontextu a podobně. Monáda je všudypřítomný vzor
Tomu všemu rozumím, jen mi to přišlo legrační :)
-
neexistuje žádná obrana před tím proč by zrovna ve Vašem kódu nemohlo nastat přetečení zásobníku.
Existuje - ten zásobník prostě nevyužíváš. Triviální příklad: místo rekurze dáš for.
Tomu všemu rozumím, jen mi to přišlo legrační :)
Co je na tom legračního?
-
Také tím můžete zajistit, aby vám nepřetekl zásobník.
To žijete ve velkém omylu. Počáteční velikost zásobníku se dá volně měnit takže nevíte jak je velký a nikdy nevíte co tam kdo nasyslil před Vámi, neexistuje žádná obrana před tím proč by zrovna ve Vašem kódu nemohlo nastat přetečení zásobníku. Zrovna v C/C++ se často ještě před prvním řádkem uživatelského kódu alokuje na zásobníku.
Jde o to, že kód mohu pomocí monád předělat tak, že využije pouze konstantní množství paměti na zásobníku - hodně se to používá například ve Scale (viz Stackless Scala With Free Monads (http://blog.higher-order.com/assets/trampolines.pdf)).
-
Existuje - ten zásobník prostě nevyužíváš.
V C/C++ nelze neužít zásobník. Míra jeho využití je daná rozmary tvůrců kompilátoru, viděl jsem kompilátor co dělá push/pop i uvnitř FOR.
Jde o to, že kód mohu pomocí monád předělat tak, že využije pouze konstantní množství paměti na zásobníku
Konstantní nároky na zásobník jsou OK. Ale to šlo vždycky, monády na to nemají patent.
-
Konstantní nároky na zásobník jsou OK. Ale to šlo vždycky, monády na to nemají patent.
Tak samozřejmě, mluvíme přece o výpočetně úplných jazycích. Monády "jen" výrazně ulehčují programátorovi práci. Stejně jako všechno ostatní co kdy bylo kolem programovacích jazyků vymyšleno. :)
-
V C/C++ nelze neužít zásobník. Míra jeho využití je daná rozmary tvůrců kompilátoru, viděl jsem kompilátor co dělá push/pop i uvnitř FOR.
A small comment: Even though the C++ solution corresponds to a recursive function in Haskell, it isn't actually recursive. The Loop is not calling itself -- it creates a new Loop object. You can run this code under the debugger and see that the program's stack is not growing. Neither is heap space for that matter -- the Loop objects are constantly recycled.
https://www.fpcomplete.com/blog/2012/06/asynchronous-api-in-c-and-the-continuation-monad
-
Tak samozřejmě, mluvíme přece o výpočetně úplných jazycích. Monády "jen" výrazně ulehčují programátorovi práci. Stejně jako všechno ostatní co kdy bylo kolem programovacích jazyků vymyšleno. :)
Až to bude v jazyku pak to bude významné ulehčení. Do té doby si to nemyslím.
You can run this code under the debugger and see that the program's stack is not growing.
Autor vypozoroval chování v tomto jednom případě pro jeho zdroják. Stejné chování pro jiné případy není zaručeno nijak, kompilátor C/C++ má ohledně stacku dost velkou volnost. Dále bych se v tom nepitval, konstantní nároky na stack stačí :)
-
Až to bude v jazyku pak to bude významné ulehčení. Do té doby si to nemyslím.
To je vtip? :o Vždyť už se to používá. Jakou další podporu bys ještě chtěl?
-
Vždyť už se to používá. Jakou další podporu bys ještě chtěl?
Zvýšení pohodlí. Lambda funkce se taky daly používat odjakživa, ale až od zavedení podpory v jazycích to není spíše opruz ale spíše přínos.
-
Tento zdroják (presnejšie by sme mali povedať: dátová štruktúra jazyka C/FPP) je potom spracovaný v runtime systéme, ktorý môže byť z dôvodov efektívnosti realizovaný prekladom do strojového kódu.
Dobře, ale nerozumím romu, co se snažíš říct, kam se chceš dobrat.
Snažím sa povedať, že C/FPP je čistý funkcionálny jazyk.
Ináč som si nie istý, či som ťa správne pochopil: tým čistým funkcionálnym jazykom nazývaš len FPP alebo C/FPP?
FPP je čistý, to jsme si dali do definice. FPP produkuje string, který se dá interpretovat jako zdroják v C, což čistý jazyk není.
Nevím, jakou tam hledáš záludnost. Říkal jsem to proto, že stejným způsobem runtime Haskellu interpretuje ty IO instrukce, což je taky jenom nějaká datová struktura (jako ten string) a úplně stejným způsobem z toho NEplyne, že Haskell není čistý jazyk.
Tú otázku som tam dal preto, lebo som si nebol (a stále si nie som) istý, či sa zhodneme na čistote jazyka C/FPP. (Samozrejme, stále som si vedomý toho, že FPP nebol poriadne definovaný.)
-
Tú otázku som tam dal preto, lebo som si nebol (a stále si nie som) istý, či sa zhodneme na čistote jazyka C/FPP. (Samozrejme, stále som si vedomý toho, že FPP nebol poriadne definovaný.)
Ale C/FPP není žádný jazyk. Jazyk je buď C nebo FPP. Představ si, že bys měl jazyk BLB, který by měl jediný typ: string a jedinou operaci: RETURN. A pak bys v něm napsal takovýhle program:
RETURN '
void f() {
puts("Hola hola hola\n");
}
int main () {
f();
return 0;
}
'
Znamená to snad, že "jazyk BLB/C" má funkce? Že umí vypsat něco na výstup? Ne. Žádný jazyk BLB/C neexistuje, tím míň se dá mluvit o nějakých jeho vlastnostech.
-
Tú otázku som tam dal preto, lebo som si nebol (a stále si nie som) istý, či sa zhodneme na čistote jazyka C/FPP. (Samozrejme, stále som si vedomý toho, že FPP nebol poriadne definovaný.)
Ale C/FPP není žádný jazyk.
Ale áno, je. Má jasne definovanú syntax aj sémantiku a tiež runtime prostredie. (Teda mal by, keby sme dorobili detaily.)
Jazyk je buď C nebo FPP.
Alebo C/FPP. To predsa závisí len od definície syntaxe a sémantiky tohto jazyka. Asi ťa pletie, že tento úplne nový jazyk C/FPP (navyše s nešťastne zvoleným názvom) má toľko spoločného s jazykom C. Pokojne si môžeš predstaviť, že začneme s úplne novým jednoduchým funkcionálnym jazykom trebárs obsahujúcim monády a k nemu si definujeme taktiež úplne nový imperatívny jazyk (trebárs assembler nejakého virtuálneho procesora alebo priamo strojový kód, nech ten nový čistý funkcionálny jazyk naozaj stojí za to), ktorý bude vykonávaný v runtime prostredí. Na záver zvolíme vhodnejší názov, trebárs PURE.
Môžeš mi opäť napísať o Eiffelovej veži a zmrzline a hľadať v odkazovanom blogu formálne nedostatky na povrchu, alebo sa môžeš skúsiť naozaj zamyslieť nad tým, čo chcel autor toho blogu povedať. A myslím si, že práve s príkladmi takýchto čistých funkcionálnych jazykov majú mnohí ľudia problémy. Zrejme práve k tomu smerovala aj námietka Greenhorna, akurát zvolil trochu nešťastnú metódu, keď chcel k C-čku pridávať monády a vyrábať z neho čistý funkcionálny jazyk. Radek Miček síce správne poukázal na problémy s tým spojené, obávam sa však, že to nejasnosti Greenhorna vôbec nezodpovedalo. (Neviem čítať myšlienky ani nemôžem hovoriť za neho, to len odhadujem z analogických problémov, ktoré mávajú v diskusiách iní ľudia.)
Představ si, že bys měl jazyk BLB, který by měl jediný typ: string a jedinou operaci: RETURN. A pak bys v něm napsal takovýhle program:
RETURN '
void f() {
puts("Hola hola hola\n");
}
int main () {
f();
return 0;
}
'
Znamená to snad, že "jazyk BLB/C" má funkce? Že umí vypsat něco na výstup?
Nijaký jazyk BLB/C sme si nedefinovali. Máme iba jazyk BLB, ktorý vypisuje nejaký text, v tomto prípade C-čkovský zdroják.
Ne. Žádný jazyk BLB/C neexistuje, tím míň se dá mluvit o nějakých jeho vlastnostech.
Správne, pokiaľ si taký jazyk nedefinujeme, tak neexistuje a nemá zmysel hovoriť o jeho vlastnostiach. To by sa zmenilo v okamihu, keby sme taký jazyk definovali. V tomto prípade by zrejme nasledovala obšírna definícia runtime prostredia schopného vykonávať C-čkovské programy. (A kvôli zamedzeniu nedorozumeniam by sme ho z BLB/C premenovali na BLBOST.)
-
Správne, pokiaľ si taký jazyk nedefinujeme, tak neexistuje a nemá zmysel hovoriť o jeho vlastnostiach. To by sa zmenilo v okamihu, keby sme taký jazyk definovali. V tomto prípade by zrejme nasledovala obšírna definícia runtime prostredia schopného vykonávať C-čkovské programy. (A kvôli zamedzeniu nedorozumeniam by sme ho z BLB/C premenovali na BLBOST.)
I když si to nadefinuješ jak chceš, jsou jenom dvě možnosti:
1. celou syntax a sémantiku jazyka C zahrneš do definice jazyka BLBOST => jazyk BLBOST nemůže být pure, protože C není.
2. nezahrneš - jazyk BLBOST má prostě opravdu jenom return a string. Obsah stringu neřeší => jazyk BLBOST je pure, ale neumí dělat IO, neumí zkontrolovat korektnost toho C programu atd.
-
Ještě dovětek, ať si rozumíme...
2. nezahrneš - jazyk BLBOST má prostě opravdu jenom return a string. Obsah stringu neřeší => jazyk BLBOST je pure, ale neumí dělat IO, neumí zkontrolovat korektnost toho C programu atd.
Hlavní problém je v tom, že jazyk BLBOST nepřináší žádné výhody čistého funkcionálního jazyka, je to pořád jenom "(s)prosté céčko". Teprve pokud bych s těmi datovými strukturami mohl nějak manipulovat, tak by mi to něco přineslo. Jenže to bych musel tomu céčku uvnitř stringu rozumět => varianta 1
-
Správne, pokiaľ si taký jazyk nedefinujeme, tak neexistuje a nemá zmysel hovoriť o jeho vlastnostiach. To by sa zmenilo v okamihu, keby sme taký jazyk definovali. V tomto prípade by zrejme nasledovala obšírna definícia runtime prostredia schopného vykonávať C-čkovské programy. (A kvôli zamedzeniu nedorozumeniam by sme ho z BLB/C premenovali na BLBOST.)
I když si to nadefinuješ jak chceš, jsou jenom dvě možnosti:
1. celou syntax a sémantiku jazyka C zahrneš do definice jazyka BLBOST => jazyk BLBOST nemůže být pure, protože C není.
2. nezahrneš - jazyk BLBOST má prostě opravdu jenom return a string. Obsah stringu neřeší => jazyk BLBOST je pure, ale neumí dělat IO, neumí zkontrolovat korektnost toho C programu atd.
3. Syntax a sémantika jazyka C bude súčasťou definície runtimu jazyka C/FPP.
=> jazyk C/FPP bude čistý, lebo FPP je čistý
=> jazyk C/FPP bude schopný nielen skontrolovať syntaktickú správnosť, ale aj vykonávať program v jazyku C, lebo syntax a sémantika jazyka C sú súčasťou definície runtimu
Len dodávam, že variant (1) zodpovedá prístupu, ktorý zvolil Greenhorn a variant (2) zodpovedá tvojej predstave C/FPP ako dvoch rozličných jazykov.
(Snáď nevadí, že som sa opäť vrátil k C/FPP namiesto jazyka BLBOST, ktorý je naozaj ešte väčší extrém než pôvodný C/CPP, kde ti vadila turingovská neúplnosť CPP.)
Hlavní problém je v tom, že jazyk BLBOST nepřináší žádné výhody čistého funkcionálního jazyka, je to pořád jenom "(s)prosté céčko".
Áno, v tomto zmysle je to ešte extrémnejší príklad než pôvodné C/CPP.
Teprve pokud bych s těmi datovými strukturami mohl nějak manipulovat, tak by mi to něco přineslo. Jenže to bych musel tomu céčku uvnitř stringu rozumět => varianta 1
Alebo variant (3). A dodávam, že pri vhodnej definícii FPP sa v jazyku C/FPP môže dať celkom dobre pracovať aj bez využitia jeho "C-monády". No a v prípade potreby (alebo len chuti) môžeš v "C-monáde" písať ten najšpinavší imperatívny kód akého budeš schopný a stále bude všetko funkcionálne čisté.
-
3. Syntax a sémantika jazyka C bude súčasťou definície runtimu jazyka C/FPP.
=> jazyk C/FPP bude čistý, lebo FPP je čistý
=> jazyk C/FPP bude schopný nielen skontrolovať syntaktickú správnosť, ale aj vykonávať program v jazyku C, lebo syntax a sémantika jazyka C sú súčasťou definície runtimu
Potom jsi ale změnil běžné chápání pojmu "runtime", protože ten běžně žádnou syntax nemá a nekontroluje, protože nic nepřekládá. Jen vykonává nějaký kód (např. VM Javy).
Pak teda jsou dvě možnosti:
1. To, co popisuješ, je vlastně normální transpiller. Např. jazyk PureScript je čistý a překládá se do JavaScriptu, který čistý není.
2. Nejde o transpiller, ale fungovalo by to tak, že PureScript by svým během generoval JavaScript.
A co z toho všeho teda vyvozuješ? Proč se o tom vlastně bavíme?
-
3. Syntax a sémantika jazyka C bude súčasťou definície runtimu jazyka C/FPP.
=> jazyk C/FPP bude čistý, lebo FPP je čistý
=> jazyk C/FPP bude schopný nielen skontrolovať syntaktickú správnosť, ale aj vykonávať program v jazyku C, lebo syntax a sémantika jazyka C sú súčasťou definície runtimu
Potom jsi ale změnil běžné chápání pojmu "runtime", protože ten běžně žádnou syntax nemá a nekontroluje, protože nic nepřekládá. Jen vykonává nějaký kód (např. VM Javy).
Pak teda jsou dvě možnosti:
1. To, co popisuješ, je vlastně normální transpiller. Např. jazyk PureScript je čistý a překládá se do JavaScriptu, který čistý není.
2. Nejde o transpiller, ale fungovalo by to tak, že PureScript by svým během generoval JavaScript.
A co z toho všeho teda vyvozuješ? Proč se o tom vlastně bavíme?
Píše se "transpiLer". Nepoužíváme cizí slova, která neumíme napsat ;)
-
Píše se "transpiLer".
Jistě. Děkuji za tuto velmi důležitou připomínku.
-
3. Syntax a sémantika jazyka C bude súčasťou definície runtimu jazyka C/FPP.
=> jazyk C/FPP bude čistý, lebo FPP je čistý
=> jazyk C/FPP bude schopný nielen skontrolovať syntaktickú správnosť, ale aj vykonávať program v jazyku C, lebo syntax a sémantika jazyka C sú súčasťou definície runtimu
Potom jsi ale změnil běžné chápání pojmu "runtime", protože ten běžně žádnou syntax nemá a nekontroluje, protože nic nepřekládá. Jen vykonává nějaký kód (např. VM Javy).
Kontrolu syntaxe samozrejme vykoná kompilátor C/FPP v rámci typovej kontroly, pretože "C" (alebo "C-monáda", či ako si to nazveme) je len ďalší z dátových typov, hoci o poznanie zložitejší než Int. Čistota jazyka sa tým nijako nenarúša, nakoľko k vykonaniu kódu obsiahnutého v tejto dátovej štruktúre dôjde až v runtime.
Pokiaľ ide o runtime, je len otázkou implementácie, či bude vykonávaný priamo kód zapísaný programátorom (tak by tomu zrejme bolo, ak by sme za imperatívny jazyk zvolili trebárs strojový kód nejakého virtuálneho procesora, ako som popisoval v skoršom príspevku) alebo kompilátor túto dátovú štruktúru uloží v inom tvare, vhodnejšom na neskoršie vykonanie v runtime. Tento implementačný detail predsa nijako nenarúša myšlienku vyjadrenú v mojom predchádzajúcom príspevku.
Pak teda jsou dvě možnosti:
1. To, co popisuješ, je vlastně normální transpiller. Např. jazyk PureScript je čistý a překládá se do JavaScriptu, který čistý není.
2. Nejde o transpiller, ale fungovalo by to tak, že PureScript by svým během generoval JavaScript.
3. "C" resp. "C-monáda" je dátový typ jazyka C/FPP, ktorý sa vykonáva v runtime.
Variant (2) nevyhovuje: jazyk C/FPP negeneruje svojím behom program v jazyku C. V runtime sa iba vykonáva kód, ktorý už je obsiahnutý v dátovej štruktúre C-monády.
Variant (1) mi nie je jasný vôbec: malo by ísť o transpiler z C do C? Ako som písal vyššie, FPP môže byť celkom sebestačný funkcionálny jazyk, ktorého C-monádu nemusíš vôbec použiť - v tom prípade by sa teda do C nič neprekladalo. A keď ju už použiješ, tak sa v runtime vykonáva priamo tebou napísaný kód v jazyku C. Tak kde je tam transpiler?
A co z toho všeho teda vyvozuješ? Proč se o tom vlastně bavíme?
To, že C/FPP je čistý funkcionálny jazyk "obsahujúci C-čko". Už som na to predsa odpovedal. (A v predchádzjúcom príspevku som aj popísal, v akom zmysle "obsahuje C-čko": máš tam dátovú štruktúru, napríklad "C-monádu", v ktorej môžeš písať imperatívny kód v C-čku, hoci všetko zostáva funkcionálne čisté.)
-
To, že C/FPP je čistý funkcionálny jazyk "obsahujúci C-čko". Už som na to predsa odpovedal. (A v predchádzjúcom príspevku som aj popísal, v akom zmysle "obsahuje C-čko": máš tam dátovú štruktúru, napríklad "C-monádu", v ktorej môžeš písať imperatívny kód v C-čku, hoci všetko zostáva funkcionálne čisté.)
A dál? Co tím chceš teda říct?
P.S. "monáda" je v tomhle případě imho zavádějící termín, protože monáda je přesně definovaná struktura a moc si neumím z fleku představit, jak bys ji napasoval na tuhle svoji představu. Ty bys ve skutečnosti můžeš z toho FPP generovat buď string (to by ale neodpovídalo tvé definici, protože by se ti s tím stringem obtížně manipulovalo), nebo spíš AST (naparsované céčko). Ke generování AST monádu nepotřebuješ.
-
P.P.S. Úplně stejně můžeš místo "FPP/C" mít jazyk, který podporuje makra - tam pak máš de facto taky "dvě vrstvy jazyka". Pokud by sis tu první (makrosystém) omezil tak, aby byla čistá, a ta druhá by čistá nebyla, máš totéž a bez lopocení se s nějakým céčkem...
viz http://elixir-lang.org/getting-started/meta/macros.html - pokud bys makra předefinoval tak, aby byla čistá a případně i lazy, seš tam, kde chceš být.
-
To, že C/FPP je čistý funkcionálny jazyk "obsahujúci C-čko". Už som na to predsa odpovedal. (A v predchádzjúcom príspevku som aj popísal, v akom zmysle "obsahuje C-čko": máš tam dátovú štruktúru, napríklad "C-monádu", v ktorej môžeš písať imperatívny kód v C-čku, hoci všetko zostáva funkcionálne čisté.)
A dál? Co tím chceš teda říct?
Ďalej už nič. To, čo som chcel povedať, bolo v základe vyjadrené už v mojom prvom príspevku. Zvyšok bol už len vysvetľovaním. Príklad "čistého funkcionálneho jazyka obsahujúceho C-čko" skrátka považujem za vhodný ilustračný príklad, nakoľko u mnohých ľudí (súdiac podľa rozličných diskusií) predstava čistého funkcionálneho jazyka nezodpovedá definícii. (A k tomu som dával aj ten príklad so spojitými funkciami, aby sa rozplynuli hmly aj nad touto mojou analógiou.)
P.S. "monáda" je v tomhle případě imho zavádějící termín, protože monáda je přesně definovaná struktura a moc si neumím z fleku představit, jak bys ji napasoval na tuhle svoji představu. Ty bys ve skutečnosti můžeš z toho FPP generovat buď string (to by ale neodpovídalo tvé definici, protože by se ti s tím stringem obtížně manipulovalo), nebo spíš AST (naparsované céčko). Ke generování AST monádu nepotřebuješ.
Netvrdil som, že to musí byť robené práve cez monády, hoci aj tie môžu byť užitočné. Môžeme si predstaviť trebárs "CF-monádu" obsahujúcu C-čkovské filtre a spájanie monád by v takom prípade fungovalo ako rúra. (Snáď je táto myšlienka na linuxovom fóre dostatočne zrejmá aj bez ďalšieho popisu.)
P.P.S. Úplně stejně můžeš místo "FPP/C" mít jazyk, který podporuje makra - tam pak máš de facto taky "dvě vrstvy jazyka". Pokud by sis tu první (makrosystém) omezil tak, aby byla čistá, a ta druhá by čistá nebyla, máš totéž a bez lopocení se s nějakým céčkem...
viz http://elixir-lang.org/getting-started/meta/macros.html - pokud bys makra předefinoval tak, aby byla čistá a případně i lazy, seš tam, kde chceš být.
Áno, veď v pôvodnom odkaze bolo práve makro, išlo predsa o C/CPP. Tento príklad si však vtedy označil za zavádzajúci, a tak sme si to trochu poobjasňovali.
-
Netvrdil som, že to musí byť robené práve cez monády, hoci aj tie môžu byť užitočné. Môžeme si predstaviť trebárs "CF-monádu" obsahujúcu C-čkovské filtre a spájanie monád by v takom prípade fungovalo ako rúra. (Snáď je táto myšlienka na linuxovom fóre dostatočne zrejmá aj bez ďalšieho popisu.)
K tomu pořád ale monády nepotřebuješ. Pokud je výstupem AST, je pořadí operací jasně dané (pokud ten "cílový jazyk" - tady C - není taky čistý). Monády jsou prostě způsob, jak řadit něco, co by jinak seřadit nebylo možno. Nic víc, nic míň.
Monády bys začal potřebovat, pokud bys chtěl tím céčkem něco načítat do toho FPP. Tam by ses dostal do toho problému, který monády řeší.
Áno, veď v pôvodnom odkaze bolo práve makro, išlo predsa o C/CPP. Tento príklad si však vtedy označil za zavádzajúci, a tak sme si to trochu poobjasňovali.
No jenže makra v CPP a makra v Elixiru nebo Lispu, jsou něco dost jiného :) A ta hlavní věc, co je odlišuje, je to, co jsem říkal: CPP není turingovsky úplný. V Elixiru nebo Lispu makrojazyk je úplný (protože je to sám Elixir nebo Lisp).
-
Netvrdil som, že to musí byť robené práve cez monády, hoci aj tie môžu byť užitočné. Môžeme si predstaviť trebárs "CF-monádu" obsahujúcu C-čkovské filtre a spájanie monád by v takom prípade fungovalo ako rúra. (Snáď je táto myšlienka na linuxovom fóre dostatočne zrejmá aj bez ďalšieho popisu.)
K tomu pořád ale monády nepotřebuješ. Pokud je výstupem AST, je pořadí operací jasně dané (pokud ten "cílový jazyk" - tady C - není taky čistý).
Poradie operácií je dané vnútri samotnej dátovej štruktúry C, nie pri spájaní niekoľkých takýchto štruktúr, z ktorých každá môže mať vedľajšie efekty. Ale toto predsa nebolo pre môj príklad C/FPP podstatné.
Áno, veď v pôvodnom odkaze bolo práve makro, išlo predsa o C/CPP. Tento príklad si však vtedy označil za zavádzajúci, a tak sme si to trochu poobjasňovali.
No jenže makra v CPP a makra v Elixiru nebo Lispu, jsou něco dost jiného :)
Tak to je skutočný objav, ešteže si ma na to upozornil. ;D
A ta hlavní věc, co je odlišuje, je to, co jsem říkal: CPP není turingovsky úplný.
A preto som ti hneď na začiatku napísal, že si namiesto CPP môžeš predstaviť nejaký čistý funkcionálny, turingovsky úplný predprocesor FPP.
V Elixiru nebo Lispu makrojazyk je úplný (protože je to sám Elixir nebo Lisp).
Lisp predsa nie je čistý, to by si tam mohol dať rovno m4. Viem síce, že to vieš, ale keď sa už upozorňujeme na samozrejmé veci... :)
-
...debatě třeba o těch záměrných nedokonalostech typového systému Swiftu...
Kde je ta údajná nedokonalost?
-
Kde je ta údajná nedokonalost?
http://forum.root.cz/index.php?topic=11417.msg134798#msg134798
-
Kde je ta údajná nedokonalost?
http://forum.root.cz/index.php?topic=11417.msg134798#msg134798
To není nedokonalost, konzistentní kontrola typů z principu napsat nejde (pro turingovsky úplný jazyk, což Swift je).
-
To není nedokonalost, konzistentní kontrola typů z principu napsat nejde (pro turingovsky úplný jazyk, což Swift je).
Můžeš to nějak doložit? Zaprvé v tom odkazovaném článku se píše opak, za druhé, umím si představit jazyk s jediným typem, který bude T.Ú., takže si neumím představit, proč by to nemělo být možný.
-
To není nedokonalost, konzistentní kontrola typů z principu napsat nejde (pro turingovsky úplný jazyk, což Swift je).
Můžeš to nějak doložit? Zaprvé v tom odkazovaném článku se píše opak, za druhé, umím si představit jazyk s jediným typem, který bude T.Ú., takže si neumím představit, proč by to nemělo být možný.
Ono to je celkem triviální pozorování. Viz zde: http://gallium.inria.fr/~remy/mpri/cours1.pdf
-
Ono to je celkem triviální pozorování. Viz zde: http://gallium.inria.fr/~remy/mpri/cours1.pdf
Myslíš stranu 29 dole - "Soundness versus completeness"? Ten odstavec mi není jasný (co je "a program goes wrong"?) bez toho, abych to celý četl, což dělat nebudu :) ale není to náhodou jenom připomenutí Goedelovy vety o neuplnosti? Není to něco trochu jinýho, než o čem je řeč?
-
Ono to je celkem triviální pozorování. Viz zde: http://gallium.inria.fr/~remy/mpri/cours1.pdf
Myslíš stranu 29 dole - "Soundness versus completeness"? Ten odstavec mi není jasný (co je "a program goes wrong"?) bez toho, abych to celý četl, což dělat nebudu :) ale není to náhodou jenom připomenutí Goedelovy vety o neuplnosti? Není to něco trochu jinýho, než o čem je řeč?
"a program goes wrong" může být IMHO třeba dělení nulou