Má Haskell budoucnost?

[Radek Miček]

Ale jinak: Pro ty, kteří opravdu bazírují na výkonnosti tu máme https://ghc.haskell.org/trac/ghc/wiki/StrictPragma. Stačí to dát na začátek modulu (nebo do Cabalu) a jede se... ale osobně kromě snad nějakého výpočetního důvodu to fakt nemám důvod použít.

Mě spíš trápí to, že nevím, co přesně ten můj program kdy vyhodnocuje. Kromě zmíněného space leaku to komplikuje i profilování. (Na jednu stranu je hezké, že se Haskell inspiroval algebrou, na druhou stranu řadu lidí, co dělala algebru, nezajímala časová a prostorová složitost používaných technik, což se do Haskellu přeneslo a teď se to někteří lidé snaží opravit. Například u některých monád (nebo u některých implementací) ovlivňuje asociativita asymptotickou časovou složitost - například u monády strom (bind nahrazuje listy stromu jinými podstromy) se můžete dostat z lineární na kvadratickou).

BTW ta výhoda s nevyhodnocením defaultní hodnoty v Haskellu je vyvážena nutnostní duplikovat funkce pro monády - například, pokud by výpočet defaultní hodnoty používal vstup a výstup (tj. byl v IO monádě), tak budu potřebovat speciální verzi fromMaybe.

Další věc jsou líné datové struktury, jejichž vyhodnocování může způsobovat vedlejší efekty - hádám, že to v Haskellu nebude jednodušší než třeba ve Scale.

Tak to je dobře (GoodThing), že to neslinkuje Proto taky GHC varuje před OrphanInstances a když jsou v knihovně OrphanInstances tak to je BadThing.

Vytvářet OrphanInstances mi přijde jako hlavní výhoda typových tříd oproti rozhraním z Javy a spol.

Nestává se vám, že máte dvě knihovny - jedna definuje typovou třídu, druhá typ a vy zrovna potřebujete instanci typové třídy z první knihovny pro typ z druhé knihovny?

On na první pohled ten newtype vypadá "kostrbatě", ale mě třeba připadá, že jinak to stejně nejde - nebylo by to "composable".

Problém je, že po zabalení do newtype už ta zabalená hodnota nejde použít v místě, kde je vyžadován původní typ (musím hodnotu zase rozbalit). Ve Scale na to jde použít tagování - například od typu Int přejdu k Int @@ Product, což je podtyp Int, tj. mohu to použít kdekoliv je vyžadován Int.

Třeba jsem řešil, že chci ve FromJSON struktuře deserializovat něco jinak, než je v default typeclass - třeba některá čísla tam jsou hexadecimálně ve stringu. A nevím, jak by se tohle řešilo - přiřadit typeclass konkrétní položce v recordu? A pak ta hodnota bude i s tou typeclass někde cestovat?

Ve Scale by se to řešilo tak, že uděláte typovou třídu pro typ Int a pro typ Int @@ Hex - v záznamu pak použiji typ Int @@ Hex pro pole, která jsou hexadecimálně. Jelikož Int @@ Hex je podtyp Int, jde s ním pracovat stejně jako s Intem.

Instance typových tříd ve Scale jsou hodnoty nebo funkce označené klíčovým slovem implicit a kompilátor je hledá v tzv. implicit scope - když chci použít jinou instanci, stačí například importovat modul.

[Reklama]

[Mirek Prýmek]

Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí.

Tomu nerozumím. Možná myslíš jakýkoli program bez vedlejších efektů? Nebo jakýkoli program přeložený do nějakého aparátu, který v lazy prostředí umožňuje vedlejší efekty řadit? A jak bych si vůbec měl představit program v Pythonu "fungující v prostředí" Haskellu?

Jenomže to je monadická záležitost. Pure FP, kde je laziness vidět nejvíc, je spíš něco jako "projektový plán". A "krizový management" taky nevyhodnocuješ "eager", ale teprve až v momentě, kdy přijde krize.

Nevím, co myslíš tím "monadická záležitost". Haskell prostě může cokoli vyhodnotit kdykoli, takže kdybych dal za sebe

Kód: [Vybrat]

print "a"
print "b"
tak mi to může vypsat "a\nb\n" i "b\na\n".

Protože to pořadí chci zachovat, musím udělat tu opičku s tím, že oba printy uzavřu do lambd, trochu to ošperkuju tak, aby mi typový systém zaručil spuštění ve správném pořadí a to, jak je to vlastně udělaný, je obtížný pochopit, zatímco v eage jazyce je to prostě a jednoduše

Kód: [Vybrat]

print "a"
print "b"
bez jakékoli další bižuterie.

Tomu říkáš "co je na tom za komplikaci"?

Když mě to vysvětlení, že to je programovatelný středník připadá, že to vlastně ani není analogie.

Není to analogie. Mně na do notaci vadí to, že uměle zavádí pojmy z eager imperativního programování do prostředí, kde mají úplně jiný význam. Prostě return není žádný return a říkat mu return nadělá víc škody než užitku.

[Mirek Prýmek]

Slovo "monoid" se tady na fóru nevyslovuje (pokud teda - podle některých - nejsi autista)

Ty můžeš, o tobě to stejně všichni už víme

[v]

Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí.

Tomu nerozumím. Možná myslíš jakýkoli program bez vedlejších efektů? Nebo jakýkoli program přeložený do nějakého aparátu, který v lazy prostředí umožňuje vedlejší efekty řadit? A jak bych si vůbec měl představit program v Pythonu "fungující v prostředí" Haskellu?

program v haskellu napsaný tak jako by haskell byl eager bude fungovat v lazy haskellu stejně jako v tom teoretickém eager

[Kit]

Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí.

Tomu nerozumím. Možná myslíš jakýkoli program bez vedlejších efektů? Nebo jakýkoli program přeložený do nějakého aparátu, který v lazy prostředí umožňuje vedlejší efekty řadit? A jak bych si vůbec měl představit program v Pythonu "fungující v prostředí" Haskellu?

program v haskellu napsaný tak jako by haskell byl eager bude fungovat v lazy haskellu stejně jako v tom teoretickém eager

I když se za běhu rozštěpí do více vláken?

[Reklama]

[andy]

Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí.

Tomu nerozumím. Možná myslíš jakýkoli program bez vedlejších efektů? Nebo jakýkoli program přeložený do nějakého aparátu, který v lazy prostředí umožňuje vedlejší efekty řadit? A jak bych si vůbec měl představit program v Pythonu "fungující v prostředí" Haskellu?

program v haskellu napsaný tak jako by haskell byl eager bude fungovat v lazy haskellu stejně jako v tom teoretickém eager

Tak. Prostě když budu mít kód přeložený se Language Strict, StrictData a tu direktivu odstranim, tak to bude davat stejne vysledky. Tak proč by to meli začátečníci řešit?

[andy]

Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí.

Tomu nerozumím. Možná myslíš jakýkoli program bez vedlejších efektů? Nebo jakýkoli program přeložený do nějakého aparátu, který v lazy prostředí umožňuje vedlejší efekty řadit? A jak bych si vůbec měl představit program v Pythonu "fungující v prostředí" Haskellu?

program v haskellu napsaný tak jako by haskell byl eager bude fungovat v lazy haskellu stejně jako v tom teoretickém eager

I když se za běhu rozštěpí do více vláken?

Ano.

[Radek Miček]

Jakýkoliv strict program funguje úplně v pohodě v lazy prostředí.

Tomu nerozumím. Možná myslíš jakýkoli program bez vedlejších efektů? Nebo jakýkoli program přeložený do nějakého aparátu, který v lazy prostředí umožňuje vedlejší efekty řadit? A jak bych si vůbec měl představit program v Pythonu "fungující v prostředí" Haskellu?

program v haskellu napsaný tak jako by haskell byl eager bude fungovat v lazy haskellu stejně jako v tom teoretickém eager

Tak. Prostě když budu mít kód přeložený se Language Strict, StrictData a tu direktivu odstranim, tak to bude davat stejne vysledky.

A nemůže se stát, že program začne padat na přetečení zásobníku?

[v]

A nemůže se stát, že program začne padat na přetečení zásobníku?

nenapadá mě jak, máte takový příklad?

[Ivan Nový]

Z Wikipedie hesla Leibnitz a filosofie :-) :

Co jsou monády?

    Monády jsou body. To znamená, že vlastní prazáklad jsoucna jsou bodové substance. Tento základ tedy není kontinuum. Zdá se to být v rozporu se smyslovou zkušeností, látky se nám zdají jako rozlehlé kontinuum. Leibniz tvrdí, že tento smyslový dojem klame.
    Monády jsou síly, silová centra. Těleso není nic jiného než komplex bodových silových center.
    Monády jsou duše. Bodové monády jsou oduševnělé, ale liší se ve schopnosti představ – percepce. Nejnižší monády jsou jakoby ve stavu snu či omámení, mají jen temné, nevědomé představy. Prostřední monády mají jakési mlhavé představy, jsou schopné odlišit své představy od ostatních, ale už ne rozlišovat jednotlivé představy mezi sebou. Vyšší monády, jako je lidská duše, mají vědomí, schopnost percepce a apercepce – sebeuvědomění, reflexe apod. A nejvyšší monáda, bůh, má nekonečné vědomí, je vševědoucí.
    Monády jsou individua. Neexistují dvě stejné monády. Každá monáda, od té nejjednodušší k nejsložitější, má své nezaměnitelné místo, každá zrcadlí univerzum svým vlastním, jedinečným způsobem a každá je potenciálně, co do možnosti, zrcadlem univerza. Monády jsou individua také v tom smyslu, že jsou navenek uzavřeny – nemají žádná „okna“ – neovlivňují se.

A z toho čerpá i FP, monáda je jedinečná "šablona" nějakého projevu reálného světa.

[v]

A nemůže se stát, že program začne padat na přetečení zásobníku?

nenapadá mě jak, máte takový příklad?

jasně, zřídka čtený, často inkrementovaný čítač

[Radek Miček]

A nemůže se stát, že program začne padat na přetečení zásobníku?

nenapadá mě jak, máte takový příklad?

jasně, zřídka čtený, často inkrementovaný čítač

Ano, něco na ten způsob. Vycházel jsem z rozdílu mezi

Kód: [Vybrat]

foldl (+) 0 [1..1000000]
foldl' (+) 0 [1..1000000]

kde oba řádky sčítají čísla ze seznamu. První však spadne na přetečení zásobníku, druhý projde.

[v]

mi se vybavilo toto:
https://hackage.haskell.org/package/base-4.8.2.0/docs/Data-IORef.html#v:modifyIORef

[zboj]

Slovo "monoid" se tady na fóru nevyslovuje (pokud teda - podle některých - nejsi autista)

Ty můžeš, o tobě to stejně všichni už víme

Máš zajímavou definici opaku "lempl na matematiku", ale brát ti ji nebudu

[andy]

BTW ta výhoda s nevyhodnocením defaultní hodnoty v Haskellu je vyvážena nutnostní duplikovat funkce pro monády - například, pokud by výpočet defaultní hodnoty používal vstup a výstup (tj. byl v IO monádě), tak budu potřebovat speciální verzi fromMaybe.

To je ale spíš dané pure/non-pure rozdělením než laziness...

Další věc jsou líné datové struktury, jejichž vyhodnocování může způsobovat vedlejší efekty - hádám, že to v Haskellu nebude jednodušší než třeba ve Scale.

No v Haskellu vyhodnocování žádné vedlejší efekty nemá... (teda pominu-li historické chyby typu hGetContents a jsem spoluzodpovědný za to, že se to zrušilo z jedné další knihovny).

Vytvářet OrphanInstances mi přijde jako hlavní výhoda typových tříd oproti rozhraním z Javy a spol.

Nestává se vám, že máte dvě knihovny - jedna definuje typovou třídu, druhá typ a vy zrovna potřebujete instanci typové třídy z první knihovny pro typ z druhé knihovny?

Stává, a mělo by to být definované v jedné z těch 2 knihoven - jenomže občas na to autor nemyslel a jindy se mu nechtělo přidělávat si dependence. Pokud píšu výsledný program, tak ty orphan instance udělám, ale v knihovnách by Orphan být neměly.

Ve Scale by se to řešilo tak, že uděláte typovou třídu pro typ Int a pro typ Int @@ Hex - v záznamu pak použiji typ Int @@ Hex pro pole, která jsou hexadecimálně. Jelikož Int @@ Hex je podtyp Int, jde s ním pracovat stejně jako s Intem.

No, jenže co když mám podstrukturu, kterou jednou chci deserializovat jako Hex, jednou jako decimal? Jde to @@Hex s hodnotou, nebo je to vázané na strukturu? Možná je to nějak vymyšlené, ale numím si to úplně představit.