Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - BoneFlute

Stran: 1 ... 127 128 [129] 130 131 ... 133
1921
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 02. 07. 2015, 00:36:50 »
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.

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.

1922
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 23:53:33 »
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.

1923
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 23:24:13 »
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).

1924
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 23:09:45 »

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ž.

1925
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 23:05:57 »
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ě?

1926
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 23:02:01 »
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.)

1927
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 22:17:10 »
... 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?

1928
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 22:12:17 »
Pragmatickou stránku věci chápu.

1929
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 22:01:58 »
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.

Citace
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 :-)

1930
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 21:24:27 »
No, a ještě jsem tam měl zvýraznit to s těma side efektama.

1931
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 21:21:58 »
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á).

1932
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 20:06:31 »
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.

1933
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 01. 07. 2015, 01:36:40 »
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.

1934
Studium a uplatnění / Re:Funkcionální programátor
« kdy: 29. 06. 2015, 18:23:25 »
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.

1935
Vývoj / Re:Použití Objective-C mimo Apple
« kdy: 04. 06. 2015, 18:14:24 »
Přeruší ? O žádné přerušení Vaší činnosti jste nežádal ani jste k tomu nedával svolení :)
Tuhle logiku mi vysvětlete. Kde jste vzal implikaci, že by měl o nějak přerušení žádat? Proč by měl dávat svolení?

Stran: 1 ... 127 128 [129] 130 131 ... 133