Rychlost Haskell vs. C++

[lopata]

Myslím, že tady platí velmi trefná poznámka od JSH: ty si myslíš, že ten kód se vykonává a má chování. Jenomže ono to tak není.... Ty v podstatě v tom kódu popisuješ, jak vypadá výsledek. A odvozuješ to z "bottom". Což prostě nejde.

Ale ano jde, protože: A call to error terminates execution of the program and returns an appropriate error indication to the operating system. Pokud by tohle neplatilo, tak výsledek odvozovat nemůžu. Ale ono to platí. Takže výsledek můžu odvozovat od toho, jestli program vrátil operačnímu systému chybu, nebo ne.

[Reklama]

[andy]

Myslím, že tady platí velmi trefná poznámka od JSH: ty si myslíš, že ten kód se vykonává a má chování. Jenomže ono to tak není.... Ty v podstatě v tom kódu popisuješ, jak vypadá výsledek. A odvozuješ to z "bottom". Což prostě nejde.

Ale ano jde, protože: A call to error terminates execution of the program and returns an appropriate error indication to the operating system. Pokud by tohle neplatilo, tak výsledek odvozovat nemůžu. Ale ono to platí. Takže výsledek můžu odvozovat od toho, jestli program vrátil operačnímu systému chybu, nebo ne.

Nemůžeš. Haskell je postavený principiálně na denotational semantics, nikoliv operational semantics. Jinak pochopils, že to co děláš je fakt undefined?

[lopata]

Závisí na tom, že spadne.

Definuj spadne.

Může reálně nastat, že někoho napadne udělat podobnou věc? Může.

To není argument.

To je velmi silný argument. Nevím, jestli jsi někdy vyvíjel v týmu nebo přebíral cizí kód. Opravdu by ses divil, co se dá vymyslet za prasárny.

Zaručuje Haskell, že výsledek strict a lazy vyhodnocení bude stejný? Nezaručuje.

O tomto nikdo nemluví (a není to ani otázka Haskellu). Řeč byla o tom, že kód napsaný v Haskellu striktně (ne)pojede v lazy.

Težko se s tebou bavit, když používáš termíny jako nepojede. Pod tím si můžeš představit cokoliv. Máš nějaké předpoklady o výstupu a tomu skutečný výstup buď opovídá, nebo ne.

Musím se rozdíly mezi strict a lazy vyhodnocením zabývat, když chci ho převzít cizí kód? Musím, protože se nemůžu spoléhat na to, že někdo nevymyslí podobnou prasárnu.

A ty přebíráš někdy kód bez toho, aniž by ses podíval, co přebíráš? 
Jinak sorry, ale to není argument, stejně můžu napsat: Musím se zabývat tím, co je a co není "undefined behavior" v C, když chci převzít cizí kód? Musím, protože...

Samozřejmě se musíš zabývat undefined behavior v C, stejně jako se musíš zabývat rozdíly strict versus lazy vyhodnocení v Haskellu, to je jasná věc.

Jo, rád bych věděl, jestli jen trollíš, nebo jo...

Tady trolí úplně všichni.

[lopata]

Nemůžeš. Haskell je postavený principiálně na denotational semantics, nikoliv operational semantics. Jinak pochopils, že to co děláš je fakt undefined?

Já se klidně nechám přesvědčit, že je to undefined, prosím tedy něco z Haskell reportu, co popírá tuhle větu: A call to error terminates execution of the program and returns an appropriate error indication to the operating system.

[andy]

Nemůžeš. Haskell je postavený principiálně na denotational semantics, nikoliv operational semantics. Jinak pochopils, že to co děláš je fakt undefined?

Já se klidně nechám přesvědčit, že je to undefined, prosím tedy něco z Haskell reportu, co popírá tuhle větu: A call to error terminates execution of the program and returns an appropriate error indication to the operating system.

Ale ono ji nic nepopírá. Jenom je irelevantní. Haskellový kód by měl být interpretován podle principů "denotational semantics". Viz. https://en.wikibooks.org/wiki/Haskell/Denotational_semantics. Ta věta výše popisuje operational semantics, což je vzhledem k sémantice kódu irelevantní. Prostě ten tvůj kód podle denotational semantics netestuje dělitelnost nulou, jenom to tak podle operational semantics většinou vyjde.

[Reklama]

[lopata]

Ale ono ji nic nepopírá. Jenom je irelevantní. Haskellový kód by měl být interpretován podle principů "denotational semantics". Viz. https://en.wikibooks.org/wiki/Haskell/Denotational_semantics. Ta věta výše popisuje operational semantics, což je vzhledem k sémantice kódu irelevantní. Prostě ten tvůj kód podle denotational semantics netestuje dělitelnost nulou, jenom to tak podle operational semantics většinou vyjde.

No a? Já říkám od začátku, že je to prasárna, ale není to undefined behavior. Haskell zaručuje, že ten program dává deterministické výsledky, protože chování error je jasně specifikované.

[andy]

Ale ono ji nic nepopírá. Jenom je irelevantní. Haskellový kód by měl být interpretován podle principů "denotational semantics". Viz. https://en.wikibooks.org/wiki/Haskell/Denotational_semantics. Ta věta výše popisuje operational semantics, což je vzhledem k sémantice kódu irelevantní. Prostě ten tvůj kód podle denotational semantics netestuje dělitelnost nulou, jenom to tak podle operational semantics většinou vyjde.

No a? Já říkám od začátku, že je to prasárna, ale není to undefined behavior. Haskell zaručuje, že ten program dává deterministické výsledky, protože chování error je jasně specifikované.

Chování error je isomorfní s chováním undefined, viz ta definice undefined výše. Takže to je undefined.... No a v případě haskellových programů se o "behaviour" moc nebavíme, protože "behaviour" je typické pro operational semantics, nikoliv pro denotational semantics, tam žádné není...

Vzhledem k tomu, že sis ten text nepřečetl, tak ti to shrnu: haskellové programy se interpretují jako matematická rovnice. To, co jsi napsal, není vyjádřením testu na to, zda lze dělit to číslo nulou. Je to nedefinované, protože bottom je synonymomum pro nedefinovanou hodnotu a z toho nemůžeš nic odvodit. Nicméně, překladač haskellu pracuje deterministicky, dokonce jsi použil jenom instrukce popsané ve specifikaci, a následně z tvého nedefinovaného výsledku deterministicky vygeneruje kód, který "shodou okolností" vrací korektní výsledky.

Ovšem nemůžeš se pak divit, že při nějaké změně sémantiky (strikt -> lazy), která nemá na korektně napsané programy vliv, přestane ten tvůj chybný kód fungovat.

[andy]

Možná bych to shrnul takhle: tvůj kód uprostřed závisí na hodnotě undefined (to je ten error, bottom). Základní logické pravidlo říká "ex falso quod libet", aneb jakýkoliv výstup tvého programu je "správný". Takže ho nelze rozbít...

[lopata]

Nicméně, překladač haskellu pracuje deterministicky, dokonce jsi použil jenom instrukce popsané ve specifikaci, a následně z tvého nedefinovaného výsledku deterministicky vygeneruje kód, který "shodou okolností" vrací korektní výsledky.

Ale to není shodou okolností. Je ZARUČENO, že ten kód dává korektní výsledky (ve smyslu deterministické). Zaručeno je to chováním volání error, jak je popsáno v Haskell specifikaci. Je úplně jedno, jak je error v Haskellu interně implemetovaný a jestli to má něco společného s bottom, protože na interní implementaci error výsledky mého programu vůbec nezávisí. Závisí pouze na popisu chování error podle Haskell specifikace.

Ovšem nemůžeš se pak divit, že při nějaké změně sémantiky (strikt -> lazy), která nemá na korektně napsané programy vliv, přestane ten tvůj chybný kód fungovat.

Já se nedivím. Jenom bych se vyvaroval termínů jako korektně napsané (to znamená podle nějakých zvyklostí, nebo nezávisející na nespecifikovaném chování) a chybný kód (chybný protože se to tak obvykle nedělá, nebo chybný protože z definice nemůže fungovat).

[andy]

Já se nedivím. Jenom bych se vyvaroval termínů jako korektně napsané (to znamená podle nějakých zvyklostí, nebo nezávisející na nespecifikovaném chování) a chybný kód (chybný protože se to tak obvykle nedělá, nebo chybný protože z definice nemůže fungovat).

Tak ještě jednou: haskell je postavený na denotational semantics. Takže se ptáme, jaký význam má ten kód na základě nějakého "matematického" smyslu. Tvůj kód nemá význam testu na dělitelnost nulou(? nebude teď hledat). Význam tvého kódu není definovaný, protože má uprostřed bottom. Takže všechny ty výstupy, které jsi prezentoval, jsou správné.

[lopata]

Tak ještě jednou: haskell je postavený na denotational semantics. Takže se ptáme, jaký význam má ten kód na základě nějakého "matematického" smyslu.

Jak do denotational semantics zapadá error v Haskellu? Je definovaný jako bottom. Jenomže na tom můj kód vůbec nezávisí. Závisí na konkrétní implementaci chování volání error v Haskellu. Tím chci říct, že se zabýváš věcmi, které jsou irelevantní. Je úplně jedno, že error je bottom. Ten kód závisí jen na chování volání error, jak je popsáno ve specifikaci Haskellu.

[Cikáda]

Závisí na tom, že spadne.

Definuj spadne.

Jako vážně?

Může reálně nastat, že někoho napadne udělat podobnou věc? Může.

To není argument.

To je velmi silný argument. Nevím, jestli jsi někdy vyvíjel v týmu nebo přebíral cizí kód. Opravdu by ses divil, co se dá vymyslet za prasárny.

Jenže s takovým přístupem se dá zneužít cokoliv, tudíž je irelevantní na tom stavět kritiku. Židle je špatná, protože někoho může napadnout s ní mlátit lidi... úplně stejně validní.

Zaručuje Haskell, že výsledek strict a lazy vyhodnocení bude stejný? Nezaručuje.

O tomto nikdo nemluví (a není to ani otázka Haskellu). Řeč byla o tom, že kód napsaný v Haskellu striktně (ne)pojede v lazy.

Težko se s tebou bavit, když používáš termíny jako nepojede. Pod tím si můžeš představit cokoliv. Máš nějaké předpoklady o výstupu a tomu skutečný výstup buď opovídá, nebo ne.

Nepojede - nebude fungovat, v tomto kontextu. Zatím jsme se dostali jen k ukázkám kódu, které jsouna úrovni dereference NULL pointeru v C. Teď už jen abys to pochopil...

Musím se rozdíly mezi strict a lazy vyhodnocením zabývat, když chci ho převzít cizí kód? Musím, protože se nemůžu spoléhat na to, že někdo nevymyslí podobnou prasárnu.

A ty přebíráš někdy kód bez toho, aniž by ses podíval, co přebíráš? 
Jinak sorry, ale to není argument, stejně můžu napsat: Musím se zabývat tím, co je a co není "undefined behavior" v C, když chci převzít cizí kód? Musím, protože...

Samozřejmě se musíš zabývat undefined behavior v C, stejně jako se musíš zabývat rozdíly strict versus lazy vyhodnocení v Haskellu, to je jasná věc.

Takže jsme došli k tomu, jak validní argument to byl... pěkné

Jo, rád bych věděl, jestli jen trollíš, nebo jo...

Tady trolí úplně všichni.

Ne, kupodivu jsou tu i tací, co se snaží pomáhat nebo diskutovat...

[andy]

Tak ještě jednou: haskell je postavený na denotational semantics. Takže se ptáme, jaký význam má ten kód na základě nějakého "matematického" smyslu.

Jak do denotational semantics zapadá error v Haskellu? Je definovaný jako bottom. Jenomže na tom můj kód vůbec nezávisí. Závisí na konkrétní implementaci chování volání error v Haskellu. Tím chci říct, že se zabýváš věcmi, které jsou irelevantní. Je úplně jedno, že error je bottom. Ten kód závisí jen na chování volání error, jak je popsáno ve specifikaci Haskellu.

No vždyť jo. Psal jsi, že může odstranění XStrict ten tvůj rozbít. Nemůže, protože všechny výstupy, které jsi poskytl, jsou správné. Tvoje zadání umožňuje více různých výsledků.
Ano, všechny ty výstupy odpovídají specifikaci haskellu a chování error.

[andy]

Znáš tohle?

Kód: [Vybrat]

x = y.
Then x2 = xy.
Subtract the same thing from both sides:
x2 - y2 = xy - y2.
Dividing by (x-y), obtain
x + y = y.
Since x = y, we see that
2 y = y.
Thus 2 = 1, since we started with y nonzero.
Subtracting 1 from both sides,
1 = 0

Tak to je tvůj kód. Když se v kódu vyskytne undefined (tady dělení nulou), tak výsledek může být cokoliv. No a Haskell má volnost v tom, co si s tím kódem může dělat, pokud jsou ty operace ekvivalentní. Přechod Strict -> Lazy jsou všechno operace, které nemění výsledek. Takže všechny ty výsledky, které jsi psal - jsou správné. Odpovídají zadání, které jsi vyjádřil tím zdrojovým kódem.  Že to umožňuje víc správných výsledků? Jo, přesně tak jsi to zadal. Rozbije to Strict -> Lazy? Ne, jenom ti vrátí druhý možný výsledek.

[lopata]

Takže všechny ty výsledky, které jsi psal - jsou správné. Odpovídají zadání, které jsi vyjádřil tím zdrojovým kódem.  Že to umožňuje víc správných výsledků? Jo, přesně tak jsi to zadal. Rozbije to Strict -> Lazy? Ne, jenom ti vrátí druhý možný výsledek.

S tím naprosto souhlasím. Můj program dává deterministické výsledky, které se liší podle strict/lazy vyhodnocení. Je záměrně tak napsaný. To už je problém uživatele, že za správnou považuje jen tu strict variantu, i když obě dělají přesně to, co dělat mají. On totiž výsledek interpretuje až uživatel, z hlediska vykonávání programu je výsledek vždy správný, pokud nebudeme uvažovat chyby překladače apod.