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.
A viděl jste někdy aktuální hardware s mnohajádrovým CPU a rychlým SSD?Mně pracovní stanice s postarším, ale slušným šestijádrovým Xeonen startuje víc než minutu...
Čili pokud to správně chápu, tak pokud bych měl fci f, která vyhodí výjimku, tak pokud udělám (modifySTRef ref f) a následně writeSTRef a readSTRef, tak se výjimka nevyhodí, zatímco kdybych použil modifySTRef', tak se vyhodí.Tak vyzkoušeno, potvrzeno:
import Data.STRef
import Control.Monad.ST
err _ = error "Ha!"
main = do
print $ runST $ do
ref <- newSTRef 0
modifySTRef ref err
writeSTRef ref 1
readSTRef ref
Oproti tomu čárkovaná verze udělá to, že vytvoří akci, která zapíše přímo hodnotu f(x):Čili pokud to správně chápu, tak pokud bych měl fci f, která vyhodí výjimku, tak pokud udělám (modifySTRef ref f) a následně writeSTRef a readSTRef, tak se výjimka nevyhodí, zatímco kdybych použil modifySTRef', tak se vyhodí.
Pokud bylo v proměnné x, tak (modifySTRef ref f) vytváří akci, která do ní zapisuje f(x). Proto když se to udělá mockrát za sebou, tak mi tam ten stack narůstá. Viz zdroják:CitaceProstě bavili jsme se o tom, že v rámci STM se neděje* žádná tajemná nečistá inplace magie.No ten STRef je v implementaci fakt normální mutable proměnná, akorát že ukazuje na thunk, čili může obsahovat výpočet. Jestli je schopne to při dostatečné striktnosti kompiler nějak vyoptimalizovat pryč, to netuším.
modifySTRef ref f = writeSTRef ref . f =<< readSTRef ref
modifySTRef' ref f = do
x <- readSTRef ref
let x' = f x
x' `seq` writeSTRef ref x'
Ale to není monadické řetězení. Neřetězí se ti ST akce, řetězí se ti aplikace funkce, ale ta nemá s ST vůbec nic společného. Řetězením v monadu rozumím například to, že když asociuješ tu >>= operaci opačně, tak to pak má třeba kvadratickou složitost apod.Ok, nechme to být, to by asi bylo na dlouho si vyjasnit, co kdo čím myslel
No, vyhodnocuje se následující:Tak to jsme si asi v něčem nerozuměli, protože výrazu "(+ 1) . (+ 1) $ 0" já říkám zřetězení
Obsah STRef: 0
po 1 kroku replicate:
Obsah STRef: (+ 1) 0
po 2 kroku replicate
Obsah STRef: (+ 1) . (+ 1) $ 0
atd.
Ty "kroky" se neřetězí. To je úplně stejný problém jako foldl (+) 0 [1..1000000]. Je to problém laziness v pure výpočtech, nikoliv řetězení v ST monadu.
Takže jsem si napsal parser nějakých jednoduchých výrazů (většinou bool), nějaký jednoduchý popis toho dotazníku v Yamlu, frontend jsem měl v angularu, takže generátor javascriptu, který dělal online validaci a reakce všech těch položek na kliknutí (disable atp.), a generátor SQL create table se všemi nadefinovanými constrainty (to SQL má asi 450 řádek na 1 tabulku). Navíc ještě kontroloval, jestli jsou ty výrazy správně a nejsou tam překlepy v proměnných apod. Výsledek - po odladění to fungovalo naprosto bez chyby. Za ten rok, co to běželo, jsem nedostal jediný bug report - a to to v podstatě nikdo pořádně před nasazením netestoval.A kdybys to rovnou napsal v Elmu, tak seš na tom stejně a ještě ti odpadne to generování javascriptu
Já ti teď vůbec nerozumím. Řetězení lambd v monadu chápu jako řetězení ST () akcí. To se neděje. Vykonává se to stejně jako IO monad, dokonce vevnitř to je snad nějaký hodně podobný (akorát místo RealWorld tam je něco jiného). Co se může stát je, že STRef může obsahovat thunk (asi... nikdy jsem s tím nedělal), takže pokud to neforcneš, tak si v tom můžeš ten lazy pure výpočet nařetězit. Ale to nemá s ST nic společného. Ten 'zápis (toho thunku) do ST' se nikde neřetězí, ten se provede.A proč teda podle tebe v tom příkladu dojde ke stack overflow?
Tak ten vtip zní "A monad is just a monoid in the category of endofunctors". Tak prozatím to chápu tak, že "monoid" znamená v podstatě "list" nebo "stream" a "kategorie endofunktorů" znamená, že jsem z té akce v listu schopen vytáhnout hodnotu a nějak ji předat následujícím akcím..Tak to chápeš blbě
Monoid znamená, že pro tu věc platí pravidla monoidu (asociativita a existence neutrálního prvku) a endofunktor je funktor, který mapuje kategorii na sebe samu.
Dají se tedy monády přirovnat např. k pojmenovaným rourám s definovanou vnitřní strukturou?Přesně tak - to jsou právě ty koleje, o kterých jsem mluvil nedávno. A hezký je na tom to, že je zabezpečeno, že spojit jdou jenom koleje, který na sebe pasují (předchozí fce vrací IO akci stejného typu jako následující lambda bere jako vstup).
Řetězení ST akcí znamená, že se provádí sekvenčně uvnitř runST bloku. Tak jsem pochopil Andyho odpověď já. Na žádný zásobník se nic neukládá. Když STRef přepíšete, tak se předchozí hodnota ztratí. Funguje to stejně jako proměnná v C.To zjevně není pravda:
Be warned that modifySTRef does not apply the function strictly. This means if the program calls modifySTRef many times, but seldomly uses the value, thunks will pile up in memory resulting in a space leak. This is a common mistake made when using an STRef as a counter. For example, the following will leak memory and likely produce a stack overflow:https://hackage.haskell.org/package/base-4.8.2.0/docs/Data-STRef.html#v:modifySTRef
to s tím pořadím tak nějak pobírám... ale například výpis na obrazovku, je side efekt, nebo se mýlím?Je. Proto taky
Prelude> :t putStrLn
putStrLn :: String -> IO ()
a jinak, k otázce budoucnosti... další pohled: Živím se jako programátor, naučím se Haskell... bude mi to v práci k něčemu? V současné době jsem dostal firemní PC s windows, tak se chci naučit .NET... protože ta znalost mě může jednoho dne živit... ale Haskell? Krom takového toho domácího žvýkání...Existují firmy, kde se Haskell používá, ale moc jich nebude. Spíš je to imho jazyk, který programátorovi umožní uvědomit si, co je vlastně co a jak se dají některé věci řešit trochu jinak... Třeba to všudypřítomné skládání funkcí je dost inspirativní, dá se použít v jakémkoli jazyce.
Jinak Erlang byl ten AHA jazyk, kde jsem skutečně viděl, že se dá ve funkcionálním programování skutečně programovat... že to není jenom peklo s rekurzemi a dalšími úchylkami...Jj, měl jsem to podobně. Zkus ještě Elixir, ten je imho ještě lepší a s Erlangem plně kompatibilní, takže o nic nepřijdeš.
stref si můžete nastudovat sámPrvně bych musel vědět, v čem se mýlím, abych věděl, co tam mám hledat. Zatím se mi to jeví jako obdoba http://elixir-lang.org/docs/stable/elixir/Agent.html#update/3 - s tím rozdílem, že v Haskellu je to lazy, takže pokud dlouho píšu a nečtu, tak se ty lambdy kupí a přeteče zásobník.
a argument s bindio je asi jako říct, že nepotřebujete městskou hromadnou dopravu, protože se můžete svézt tramvají (viz haskell 2010 report a implementace instance Monad IO v ghc)Mám obavu, že ten argument nechápete. Prostě IO v Haskellu je totéž, jako by to byl string "načti_ze_stdio", "zapiš_do_souboru", ... a tyhle statické, symbolické popisy IO akcí by se řadily za sebe třeba do Listu. Monády jsou to samé, akorát mi umožňují předávat mezi IO akcemi libovolná data a checkovat jejich typy. Nic víc, jenom prostě řazení IO operací. Plus možnost failnout. A bindIO dělá to samé, akorát ne obecně pro jakoukoli monádu, ale jenom specificky pro IO akce. Takže (>>=) není nic jiného než zobecnění bindIO na jakoukoli monádu. (EDIT: z čehož právě plyne, že když specifikace obsahuje Monad, tak nepotřebuje explicitní bindIO, může ho schovat v implementaci, což je přesně to, co jsem řekl a nevidím tam nic nepravdivého)
TL;DR neA nechceš to nějak vyargumentovat?
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.