Má Haskell budoucnost?

[andy]

Souhlas. A teď jen nechápu, proč je teda laziness v haskellu problém...

Není to problém. Je to omezení, které způsobuje, že jednoduché věci musíš pak dělat složitě (pomocí té IO monády). Prostě je to trade off - je to krásná vlastnost, ale něco stojí (a stojí hodně). Proto většina FP jazyků jde opačnou cestou - jsou "nečisté", ale díky tomu snadněji použitelné.

Tobě "do" syntaxe připadá složitá? Jediný, co potřebuješ pochopit, je rozdíl mezi pure a non-pure funkcí. A pak se s tím programuje úplně stejně jako v jiném jazyce.
Jinak z praxy - naprosto běžně se mi stává, že něco napíšu v IO, pak tam dodám State, sem tam i nějaký Reader, občas to pak celý přesunu do úplně jiného monadu. Takhle je to docela pohodlné, představ, že bych zrovna IO měl nějak jinak mě dost děsí...

[Reklama]

[Mirek Prýmek]

strict: před vyhodnocením funkce jsou vyhodnoceny její argumenty

V tom případě by IO monádu nepotřeboval, protože řazení IO by pak šlo triviálně udělat takhle:

Kód: [Vybrat]

f(print "b",g(print "a"))
- dle té definice by pořadí výpisu nutně bylo a,b. Funkce f a g můžou dělat cokoli, může to být klidně identita.

[Mirek Prýmek]

Tobě "do" syntaxe připadá složitá? Jediný, co potřebuješ pochopit, je rozdíl mezi pure a non-pure funkcí.

Žádné non-pure fce ale neexistují

[Mirek Prýmek]

P.S. a omlouvám se, teď se na chvíli debaty nebudu účastnit, dám nezdvořile přednost paření Wolfa

P.P.S. Dohráno na úroveň Ueber! Wow wow wow! )

[Mirek Prýmek]

V tom případě by IO monádu nepotřeboval, protože řazení IO by pak šlo triviálně udělat takhle:

Ona ale ta otázka je stejně bezpředmětná, protože IO monádu nepotřebuje ani když je lazy. Těch způsobů, jak ředit IO operace, je prostě víc.

[Reklama]

[Ondra Satai Nekola]

V tom případě by IO monádu nepotřeboval, protože řazení IO by pak šlo triviálně udělat takhle:

Kód: [Vybrat]

f(print "b",g(print "a"))
- dle té definice by pořadí výpisu nutně bylo a,b. Funkce f a g můžou dělat cokoli, může to být klidně identita.

Tak to zase ne.
Ze je jazyk striktni jeste neznamena, ze je urcene poradi vyhodnocovani parametru funkce! Pouze to, ze jsou vsechny vyhodnocene jeste driv, nez se pokracuje tou funkci.

(Jinak to, co ukazujes, uz samozrejme neni pure.)

[v]

V tom případě by IO monádu nepotřeboval, protože řazení IO by pak šlo triviálně udělat takhle:

Kód: [Vybrat]

f(print "b",g(print "a"))
- dle té definice by pořadí výpisu nutně bylo a,b. Funkce f a g můžou dělat cokoli, může to být klidně identita.

Tak to zase ne.
Ze je jazyk striktni jeste neznamena, ze je urcene poradi vyhodnocovani parametru funkce! Pouze to, ze jsou vsechny vyhodnocene jeste driv, nez se pokracuje tou funkci.

(Jinak to, co ukazujes, uz samozrejme neni pure.)

tak

[Ondra Satai Nekola]

Jinak mohlo by se hodit:
https://wiki.haskell.org/What_a_Monad_is_not

[Mirek Prýmek]

Ze je jazyk striktni jeste neznamena, ze je urcene poradi vyhodnocovani parametru funkce! Pouze to, ze jsou vsechny vyhodnocene jeste driv, nez se pokracuje tou funkci.

No - a tady se právě dostáváme do toho, že v pure jazyce prostě imho těžko nadefinuješ call-by-value nějak smysluplně. Můžu ten příklad klíďopíďo přepsat takhle:

Kód: [Vybrat]

let
 x = f (print "a")
in
 g (print "b") x
- v tomhle případě taky není pořadí definováno?

(Jinak to, co ukazujes, uz samozrejme neni pure.)

A jak to poznáš bez signatury? print může být klidně pure funkce vracející IO akci.

[Mirek Prýmek]

Mimochodem, nějak ztrácím přehled, co se vlastně snažíte dokázat. Možná by nebylo od věci to jasně formulovat místo snahy chytit mě na švestkách

[Mirek Prýmek]

Jinak mohlo by se hodit:
https://wiki.haskell.org/What_a_Monad_is_not

Spíš myslím, že by se mohlo hodit triviální konstatování: nemají-li fce vedlejší efekty => žádným způsobem nemůžou ovlivňovat okolní svět => je úplně jedno, v jakém pořadí se vyhodnocují - jediný důsledek, který to může mít, je zacyklení se nebo nezacyklení => na IO to nemá žádný vliv

[Ondra Satai Nekola]

No - a tady se právě dostáváme do toho, že v pure jazyce prostě imho těžko nadefinuješ call-by-value nějak smysluplně.

Vzdyt jsi tu mel priklady...

Můžu ten příklad klíďopíďo přepsat takhle:

Kód: [Vybrat]

let
 x = f (print "a")
in
 g (print "b") x
- v tomhle případě taky není pořadí definováno?

Presne tak.

(Jinak to, co ukazujes, uz samozrejme neni pure.)

A jak to poznáš bez signatury? print může být klidně pure funkce vracející IO akci.

Tak pokud je to jenom pure funkce vracejici IO akci, tak zase nemas poradi, i kdyby bylo definovane poradi vyhodnocovani parmetru...

[Ondra Satai Nekola]

Spíš myslím, že by se mohlo hodit triviální konstatování: nemají-li fce vedlejší efekty => žádným způsobem nemůžou ovlivňovat okolní svět => je úplně jedno, v jakém pořadí se vyhodnocují - jediný důsledek, který to může mít, je zacyklení se nebo nezacyklení

Tak to pro zmenu ne...

Muzes si v tech prikadech nahradit nekonecne cykly runtime chybou...

Jinak to posledni

=> na IO to nemá žádný vliv

bys snad mohl nahlednout bez cele te serie sipek, ktera je navic spatne?

[Ondra Satai Nekola]

Mimochodem, nějak ztrácím přehled, co se vlastně snažíte dokázat. Možná by nebylo od věci to jasně formulovat místo snahy chytit mě na švestkách

Ze i v ciste pure svete ma teoreticke i prakticke (to jsou ty, kvuli kterym se nepouziva jenom lepsi lazy) dusledky (ne)striktnost

[Mirek Prýmek]

Tak pokud je to jenom pure funkce vracejici IO akci, tak zase nemas poradi, i kdyby bylo definovane poradi vyhodnocovani parmetru...

Jasně, beru zpět, celý to byla zcestná argumentace. Mohl bych si sice vynutit pořadí vyhodnocení, ale nic bych z toho neměl, protože to vyhodnocení stejně nemůže dělat IO.

Prostě na nutnosti dělání opiček kolem IO by se nic nezměnilo při jakémkoliv způsobu vyhodnocování.

Ze i v ciste pure svete ma teoreticke i prakticke (to jsou ty, kvuli kterym se nepouziva jenom lepsi lazy) dusledky (ne)striktnost

O tom přece není sporu. Ujasnili jsme si, že to má vliv na možnost zacyklení se na něčem, na čem by se výpočet zacyklit neměl. Ještě na něco jiného?