Má Haskell budoucnost?

[Mirek Prýmek]

spíš přitroublého ignorování, bindIO není standardní haskell, ale ghc

To na veci ale vubec nic nemeni.

[Reklama]

[v]

spíš přitroublého ignorování, bindIO není standardní haskell, ale ghc

To na veci ale vubec nic nemeni.

nepřijde vám jako problém, že váš "tutoriál" k IO v haskellu nefunguje se standardním interpretrem haskellu?

[gl]

To jsem nepsal já. Byla to odpověď andyho na mou otázku. Pochopil jsem to tak, že mutabilita tam je. Co jiného dělá writeSTRef?

Nevim, ja s tim praktickym Haskellem nemam zkusenosti. Ale predpokladam, ze to bude neco ve smyslu retezeni lambd, kde kazda vezme hodnotu a vrati jinou (nebo stejnou). Takze "zmena hodnoty" pak znamena za ten retezec lamb pridat dalsi.

Nebo tak neco Ale kazdopadne porad je to nejakej figl jak simulovat vlastnosti mutability v imutabilnim prostredi.

Ta nová hodnota se zapíše na stejné místo v paměti. Jinak by používání ST nedávalo smysl.

[Mirek Prýmek]

nepřijde vám jako problém, že váš "tutoriál" k IO v haskellu nefunguje se standardním interpretrem haskellu?

Ne, protoze bindovani IO je operace, kterou uzivatel nepotrebuje (prave diky monadam), takze ani ve specifikaci nemusi byt. Ale jelikoz v GHC je, da se snadno ukazat, jak IO doopravdy funguje - ze to neni zadna tajemna magie, ale jenom takovy trosku lepsi seznam IO operaci, ktery se provede jenom proto, ze se posle do main.

Ta nová hodnota se zapíše na stejné místo v paměti.

Ne. Operace "zapis neco do pameti" v cistem jazyce vubec nema co pohledavat

[v]

nepřijde vám jako problém, že váš "tutoriál" k IO v haskellu nefunguje se standardním interpretrem haskellu?

Ne, protoze bindovani IO je operace, kterou uzivatel nepotrebuje (prave diky monadam), takze ani ve specifikaci nemusi byt. Ale jelikoz v GHC je, da se snadno ukazat, jak IO doopravdy funguje - ze to neni zadna tajemna magie, ale jenom takovy trosku lepsi seznam IO operaci, ktery se provede jenom proto, ze se posle do main.

Ta nová hodnota se zapíše na stejné místo v paměti.

Ne. Operace "zapis neco do pameti" v cistem jazyce vubec nema co pohledavat

TL;DR ne

[Reklama]

[andy]

Ne. Operace "zapis neco do pameti" v cistem jazyce vubec nema co pohledavat

ST je to samé, co IO omezený na IORefy uvnitř runST a typovým systémem ošéfované tak, že výsledek může být pure. V ST v podstatě existují akce "newSTRef", což je "efekt", který "někde" naalokuje místo, a potom "readSTRef" a "writeSTRef", které tam "někam" zapíše nebo přečte. Jsou to "ST akce" - podobně jako IO akce, a v ST monadu se řetězí. No a protože ST v RealWorld nic nemění, tak je to typově možné schovat za něco typu unsafePerformIO.
Výsledený program v ST je de-fakto imperativní - obzvlášť, když si to napíšeš v do blocku. A nikdyjsem to ještě nepoužil, protože implementaci nějakých výpočetních algoritmů nedělám úplně často.

[Mirek Prýmek]

Jsou to "ST akce" - podobně jako IO akce, a v ST monadu se řetězí.

Však to je přesně to, co jsem psal:

to bude neco ve smyslu retezeni lambd

- pokud bys tam měl dostupnou operaci odpovídající bindIO, tak by to ani monáda být nemusela.

[Mirek Prýmek]

TL;DR ne

A nechceš to nějak vyargumentovat?

[v]

TL;DR ne

A nechceš to nějak vyargumentovat?

stref si můžete nastudovat sám 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)

[v]

Ne. Operace "zapis neco do pameti" v cistem jazyce vubec nema co pohledavat

ST je to samé, co IO omezený na IORefy uvnitř runST a typovým systémem ošéfované tak, že výsledek může být pure. V ST v podstatě existují akce "newSTRef", což je "efekt", který "někde" naalokuje místo, a potom "readSTRef" a "writeSTRef", které tam "někam" zapíše nebo přečte. Jsou to "ST akce" - podobně jako IO akce, a v ST monadu se řetězí. No a protože ST v RealWorld nic nemění, tak je to typově možné schovat za něco typu unsafePerformIO.
Výsledený program v ST je de-fakto imperativní - obzvlášť, když si to napíšeš v do blocku. A nikdyjsem to ještě nepoužil, protože implementaci nějakých výpočetních algoritmů nedělám úplně často.

např. https://gist.github.com/dmatveev/5993223

[Mirek Prýmek]

stref si můžete nastudovat sám

Prvně 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)

[pr]

Mirek Prýmek děkuji za vysvětlení mondád.

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?

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

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

[Mirek Prýmek]

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

Kód: [Vybrat]

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

[gl]

stref si můžete nastudovat sám

Prvně 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.

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

[Mirek Prýmek]

Ř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

Tenhle problém není u writeSTRef, protože ten předchozí stav (řetězec thunků) zahodí, takže nic nebobtná.

Z toho mi přijde, že to je zjevně řetězec lambd (thunků). EDIT: jakože řetězec modifikací stavu.