Rychlost Haskell vs. C++

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #135 kdy: 29. 08. 2018, 09:30:04 »
Může to udělat v podstatě cokoliv.
Fakt? Když je teda v typu, že to vrací Float, tak to vrátí Float nebo bottom. To je cokoliv? No když chceš...
Nebo to taky nemusí skončit a zůstat v nekonečné smyčce. Nebo to taky může udělat něco úplně jiného, pokud ten error odchytím (jen v případě, že to předtím, neskončilo v nekonečné smyčce...).

Citace
No jestli v tebou napsaném kódu běžně používáš panic pro řešení běžných stavů, tak to potěš...
Nevyjadřuj se k něčemu, o čem máš jen mlhavé představy. Panic v Rustu je defaultní chování při unwrap optionu, pokud je prázdný. To je naprosto legitimní použití, nikdo proto tomu neprotestuje a nikdo se toho nechce zbavit. V Rustu panic funguje deterministicky, narozdíl od error v Haskellu.

Ty se strašně divíš, že konstrukce, které jsou vcelku použitelné ve striktních jazycích prostě v lazy jazycích nedávají moc smysl. Ano, nedávají. Proto je taky Haskell považován za tak "těžký", protože i ten blbý error handling musíš dělat jinak.
Když error v Haskellu nedává smysl, nemá tam být. Pak totiž přijde nějaká lopata, použije ho v pure funkci (proč by ne, dělají to tak i v Prelude) a ono to má ve skutečnosti nedefinované chování...


lopata

Re:Rychlost Haskell vs. C++
« Odpověď #136 kdy: 29. 08. 2018, 09:38:34 »
Ukončení programu (ať už panicem nebo errorem) nemá být implementační záležitost. Haskell to má blbě, protože v Haskellu to implementační záležitost je a dokonce se ten program ani ukončit nemusí a zůstane v nekonečném cyklu...
Ale ono je to popsané IMO i v haskell reportu, že se to chová tak, jak se to chová. O to vůbec nejde - takhle dopadaj zkratky v diskuzích...
Aha, takže Haskell má ukončení po erroru udělané blbě, ale ono to nevadí, protože je popsané v Haskell reportu, že je to blbě... To můžu říct o C, že je dokonalý jazyk, protože všechny prasárny, které můžu v C udělat, mají popsané chování ve standardu (jako undefined behavior).

Jde o to, že se snažíš příklad rozbitého programu (v normálním flow má error) prezentovat jako "nerozbitý", který následně odstranění XStrict rozbije. Tak se ti snažím nějak vysvětlit, že pokud má v normálním flow "error", tak už to je rozbité.
Hele tohle byl jen příklad. Jsou i jiné způsoby, jak v Haskellu mít jiný výstup při strict/lazy vyhodnocení a nemusí tam být error. Třeba unsafePerformIO. Je mi jasné, že řekneš, že unsafePerformIO je prasárna (ano je) a nemá se používat. Ale reálně se unsafePerformIO používá i v některých knihovnách.

Chápu, že ty "nechceš", aby měl error takovouhle sémantiku, a protože ty to "nechceš" a tobě se "líbí", když s tím můžeš normálně pracovat, protože naprosto běžně používáš panic pro řešení chybových stavů. Tobě se "líbí", když můžeš z pure funkce vyhodit výjimku a pak s ní normálně pracovat a to, že v Haskellu tímhle způsobem nejde udělat (resp. se to nepovažuje za korektní), je prostě "špatně".
Mně je úplně jedno, jakou má error sémantiku, pro mě za mě tam vůbec nemusí být. Já ale chci, aby to bylo definované. A definicí nemyslím "většinou to skončí výpisem chyby na výstup, ale někdy taky ne, může to třeba skončit i nekonečným cyklem".

andy

Re:Rychlost Haskell vs. C++
« Odpověď #137 kdy: 29. 08. 2018, 09:51:06 »
Když error v Haskellu nedává smysl, nemá tam být. Pak totiž přijde nějaká lopata, použije ho v pure funkci (proč by ne, dělají to tak i v Prelude) a ono to má ve skutečnosti nedefinované chování...
Ale on dává smysl... říká "pokud se tohle spustilo, tak je ten kód rozbitý". Internal error. Proč by něco takového nemělo v jazyce být? Pomáhá to programátorům hledat bugy.

Nebo tam nemá být, protože přijde lopata a je strašně uražena, že se to nadá použít stejně jako panic v Rustu? Oni v tom Prelude totiž tu výjimku nechytají, což bylo první, co lopatu napadlo...

Citace
Aha, takže Haskell má ukončení po erroru udělané blbě, ale ono to nevadí, protože je popsané v Haskell reportu, že je to blbě... To můžu říct o C, že je dokonalý jazyk, protože všechny prasárny, které můžu v C udělat, mají popsané chování ve standardu (jako undefined behavior).
Ale ne... že v haskell reportu bude popsaný, že to tu výjimku vyhodí... ono to dřív (tzn. třeba před těma 20 lety) skutečně byl jeden z mála rozumných způsob error reportingu a běžně se používal - dneska je to jinak.

Citace
Hele tohle byl jen příklad. Jsou i jiné způsoby, jak v Haskellu mít jiný výstup při strict/lazy vyhodnocení a nemusí tam být error. Třeba unsafePerformIO. Je mi jasné, že řekneš, že unsafePerformIO je prasárna (ano je) a nemá se používat. Ale reálně se unsafePerformIO používá i v některých knihovnách.
WTF??? Jsou i jiné způsoby, jak C/C++/Java atd. se chovají třeba nedeterministicky. Například většina umožňuje volání ASM, externích C funkcí apod. Jasně že řekneš, že to je prasárna, ale reálně se to používá i v některých knihovnách....

Citace
Mně je úplně jedno, jakou má error sémantiku, pro mě za mě tam vůbec nemusí být. Já ale chci, aby to bylo definované. A definicí nemyslím "většinou to skončí výpisem chyby na výstup, ale někdy taky ne, může to třeba skončit i nekonečným cyklem".
No v implementaci GHC to definované máš. What's the problem? Ale to, co se ti snažím říct je, že tvoje funkce nemá definovaný výstup. A je poněkud otázka, jak má jazyk definovat chování tvého programu, který není v ten moment definovaný. No a konkrétní implementace překladače pak řeší jak tobě pomoci najít ve tvém programu tu chybu...

JSH

Re:Rychlost Haskell vs. C++
« Odpověď #138 kdy: 29. 08. 2018, 10:07:52 »
Tobě uniká základní věc, rozdíl mezi undefined behavior a definovaným ukončením programu (ať už standardně nebo chybou). Panic v Rustu NENÍ undefined behaviour. Používá se naprosto standardně, má definované chování a řeší situace, kdy nastane unrecoverable error. Zkus si trochu rozšířit obzory a nastudovat třeba tohle: https://doc.rust-lang.org/book/second-edition/ch09-03-to-panic-or-not-to-panic.html. Ukončení programu (ať už panicem nebo errorem) nemá být implementační záležitost. Haskell to má blbě, protože v Haskellu to implementační záležitost je a dokonce se ten program ani ukončit nemusí a zůstane v nekonečném cyklu... Tohle je prostě špatný design a s computer science to má společného možná jenom to, že computer science nedefinuje, co přesně se má v programu stát, když nastane unrecoverable error, takže Haskell akademici (včetně tebe) si to vyložili tak, že je to vlasně úplně jedno a nemusí to řešit. Normálním lidem to ale jedno není a řešit to chtějí.
Ani ten error v haskellu není nedefinované chování. Je to nedefinovaná hodnota funkce pro nějaký vstup. Nezapomeň, že v haskellu řešíme pure funkce. Ty nemají žádné chování. Ty mají hodnotu pro nějaké vstupy. Crash programu není hodnota funkce. Jestli si u haskellových funkcí představuješ, že "něco dělají", pak začínám chápat proč si nerozumíme.

A tohle není specifické pro Haskell. I v C (třeba v gcc) můžeš anotovat funkce jako pure. A pak může nastat přesně to samé co v haskellu. Překladač může přesouvat vyhodnocení funkce podle chuti kamkoliv. Pokud taková funkce assertí (dostala vstupy pro které nemá definovanou hodnotu), pak se chování toho (zabugovaného) programu může lišit podle nastavení optimalizací a podle spousty dalších věcí.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #139 kdy: 29. 08. 2018, 10:12:52 »
Ale on dává smysl... říká "pokud se tohle spustilo, tak je ten kód rozbitý". Internal error. Proč by něco takového nemělo v jazyce být? Pomáhá to programátorům hledat bugy.
To mi řekni, jak programátorům pomáhá hledat bugy, když to chybu nemusí vůbec vypsat a skončí to v nekonečné smyčce? Autoři Haskellu asi předpokládají, že si udělám memory dump procesu a v něm budu hledat chybovou hlášku, která zrovna nastala.

Citace
WTF??? Jsou i jiné způsoby, jak C/C++/Java atd. se chovají třeba nedeterministicky. Například většina umožňuje volání ASM, externích C funkcí apod. Jasně že řekneš, že to je prasárna, ale reálně se to používá i v některých knihovnách....
Původně debata začala tak, že jsem tvrdil, že výsledek kódu v Haskellu může záviset na lazy/strict vyhodnocení a pokud použiješ zrovna to nesprávné, může dávat jiné výsledky. To platí minimálně v případech, kdy je v Haskell kódu error nebo unsafePerformIO (asi i v jindy). Protože se obojí v reálném Haskell kódu vyskytuje, nemůžu jen tak vzít nějaký Haskell kód a přeložit ho s XStrict bez XStrict a očekávat, že dostanu stejný výsledek. Je úplně jedno, kde ta prasárna vzniká, jestli ji dělá error, unsafePerformIO nebo něco jiného, reálně se na to nemůžu vykašlat a musím se tím zabývat.

No v implementaci GHC to definované máš. What's the problem?
Takže můj program má pod GHC definované chování. What's the problem?


andy

Re:Rychlost Haskell vs. C++
« Odpověď #140 kdy: 29. 08. 2018, 10:34:13 »
Ale on dává smysl... říká "pokud se tohle spustilo, tak je ten kód rozbitý". Internal error. Proč by něco takového nemělo v jazyce být? Pomáhá to programátorům hledat bugy.
To mi řekni, jak programátorům pomáhá hledat bugy, když to chybu nemusí vůbec vypsat a skončí to v nekonečné smyčce? Autoři Haskellu asi předpokládají, že si udělám memory dump procesu a v něm budu hledat chybovou hlášku, která zrovna nastala.
Nerozumím. Konkrétní implementace Haskellu (GHC) samozřejmě vyhazuje výjimku. To, že tvůj program je nedefinovaný a jiný překladač se s tím teoreticky může vyrovnat jinak je druhá věc. Prostě ty ses tady snažil tvrdit, že tvůj program "rozbije" XStrict - jenomže tvůj program byl rozbitý už předtím. Akorát GHC ti dává možnosti to v některých případech odchytit a zpracovat. Pokud na tomhle chování závisí korektní chování tvého programu, tak jsi v podstatě v situaci různých nedefinovaných chování C/C++ - která ale klidně daný překladač může mít zcela přesně definované ve své specifikaci a dodržovat to.
Citace
Citace
WTF??? Jsou i jiné způsoby, jak C/C++/Java atd. se chovají třeba nedeterministicky. Například většina umožňuje volání ASM, externích C funkcí apod. Jasně že řekneš, že to je prasárna, ale reálně se to používá i v některých knihovnách....
Původně debata začala tak, že jsem tvrdil, že výsledek kódu v Haskellu může záviset na lazy/strict vyhodnocení a pokud použiješ zrovna to nesprávné, může dávat jiné výsledky. To platí minimálně v případech, kdy je v Haskell kódu error nebo unsafePerformIO (asi i v jindy). Protože se obojí v reálném Haskell kódu vyskytuje, nemůžu jen tak vzít nějaký Haskell kód a přeložit ho s XStrict bez XStrict a očekávat, že dostanu stejný výsledek. Je úplně jedno, kde ta prasárna vzniká, jestli ji dělá error, unsafePerformIO nebo něco jiného, reálně se na to nemůžu vykašlat a musím se tím zabývat.
Ach jo...

Ano, když odstraníš XStrict z rozbitého kódu, tak může změnit výstup.
Ano, když odstraníš/přidáš XStrict ke kódu, kde je explicitně napsáno "tento kód nebude vykonáván podle haskellové sémantiky (ať už lazy nebo strict)", tak se taky může stát vcelku cokoliv (zrovna u toho unsafePerformIO opravdu vcelku cokoliv).
Ano, když budeš mít C++ s odskokem do ASM, kde ti bude šahat na nějaké interní struktury, tak ti to taky různé jinak zcela nevinné optimalizační a další flagy můžou pěkně poprasit.

A teď co teda vlastně říkáš? Že je z tohoto hlediska Haskell na tom úplně stejně jako všechny ostatní reálně používané jazyky?

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #141 kdy: 29. 08. 2018, 12:03:14 »
Nerozumím. Konkrétní implementace Haskellu (GHC) samozřejmě vyhazuje výjimku.
To je pořád dokola. Je nějaká jazyková konstrukce (error), která se dá volat v pure funkcích. Má nedefinované chování. V konkrétní implementaci (GHC) definované chování má. Co s tím jako uživatel mám jako dělat? Nezbývá mi nic jiného, než používat GHC, protože error se používá i v Prelude. Opravdu nechci, aby měly moje programy nedefinované chování. Můžu reálně použít neco jiného, než GHC? Nemůžu. Leda že bych si předem ověřil, co konkrétně tam error dělá. Error dělá všechny Haskell programy neportabilní. Můžeš 1000x argumentovat tím, že je jedno, co se po error stane, ale reálně není. Můžu požadovat, jak je obvyklé, aby se po erroru program ukončí a vrátil nějaký exit code, když error nebudu explicitně chytat a ošetřovat (což je taky neportabilní). Jenomže Haskell mi ani takovou základní věc nezaručuje. Nedozvím se, že v programu nastala chyba, nemusí to ani skončit a vrátit exit code.

Ano, když odstraníš XStrict z rozbitého kódu, tak může změnit výstup.
Ano, když odstraníš/přidáš XStrict ke kódu, kde je explicitně napsáno "tento kód nebude vykonáván podle haskellové sémantiky (ať už lazy nebo strict)", tak se taky může stát vcelku cokoliv (zrovna u toho unsafePerformIO opravdu vcelku cokoliv).
Ano, když budeš mít C++ s odskokem do ASM, kde ti bude šahat na nějaké interní struktury, tak ti to taky různé jinak zcela nevinné optimalizační a další flagy můžou pěkně poprasit.

A teď co teda vlastně říkáš? Že je z tohoto hlediska Haskell na tom úplně stejně jako všechny ostatní reálně používané jazyky?
Ještě jsi zapomněl na případ, kdy přidám XStrict a rozbiju korektní lazy kód, ale to je celkem jedno. Ano, říkám, že Haskell na tom není líp, než ostatní reálně používané jazyky. Prakticky je na tom hůř, protože míchá dohromady strict a lazy vyhodnocení, půlka kódu se může vyhodnocovat lazy a druhá strict. Kód je závislý na konkrétním způsobu vyhodnocení, nejde to jen tak změnit a očekávat, že se nic nerozbije. Tohle je mimo možnosti běžné lopaty, stupeň volnosti je příliš vysoký, normální člověk nedomyslí důsledky a bude dělat chyby. Jazyk by měl být navržený tak, aby minimalizoval možnost udělat chybu, pro Haskell to ale bohužel neplatí.

JSH

Re:Rychlost Haskell vs. C++
« Odpověď #142 kdy: 29. 08. 2018, 12:46:58 »
Nerozumím. Konkrétní implementace Haskellu (GHC) samozřejmě vyhazuje výjimku.
To je pořád dokola. Je nějaká jazyková konstrukce (error), která se dá volat v pure funkcích. Má nedefinované chování. V konkrétní implementaci (GHC) definované chování má. Co s tím jako uživatel mám jako dělat? Nezbývá mi nic jiného, než používat GHC, protože error se používá i v Prelude. Opravdu nechci, aby měly moje programy nedefinované chování. Můžu reálně použít neco jiného, než GHC? Nemůžu. Leda že bych si předem ověřil, co konkrétně tam error dělá. Error dělá všechny Haskell programy neportabilní. Můžeš 1000x argumentovat tím, že je jedno, co se po error stane, ale reálně není. Můžu požadovat, jak je obvyklé, aby se po erroru program ukončí a vrátil nějaký exit code, když error nebudu explicitně chytat a ošetřovat (což je taky neportabilní). Jenomže Haskell mi ani takovou základní věc nezaručuje. Nedozvím se, že v programu nastala chyba, nemusí to ani skončit a vrátit exit code.

Ano, když odstraníš XStrict z rozbitého kódu, tak může změnit výstup.
Ano, když odstraníš/přidáš XStrict ke kódu, kde je explicitně napsáno "tento kód nebude vykonáván podle haskellové sémantiky (ať už lazy nebo strict)", tak se taky může stát vcelku cokoliv (zrovna u toho unsafePerformIO opravdu vcelku cokoliv).
Ano, když budeš mít C++ s odskokem do ASM, kde ti bude šahat na nějaké interní struktury, tak ti to taky různé jinak zcela nevinné optimalizační a další flagy můžou pěkně poprasit.

A teď co teda vlastně říkáš? Že je z tohoto hlediska Haskell na tom úplně stejně jako všechny ostatní reálně používané jazyky?
Ještě jsi zapomněl na případ, kdy přidám XStrict a rozbiju korektní lazy kód, ale to je celkem jedno. Ano, říkám, že Haskell na tom není líp, než ostatní reálně používané jazyky. Prakticky je na tom hůř, protože míchá dohromady strict a lazy vyhodnocení, půlka kódu se může vyhodnocovat lazy a druhá strict. Kód je závislý na konkrétním způsobu vyhodnocení, nejde to jen tak změnit a očekávat, že se nic nerozbije. Tohle je mimo možnosti běžné lopaty, stupeň volnosti je příliš vysoký, normální člověk nedomyslí důsledky a bude dělat chyby. Jazyk by měl být navržený tak, aby minimalizoval možnost udělat chybu, pro Haskell to ale bohužel neplatí.
Sorry, ale pořád dokola řešíš naprostou koninu. Prakticky ti tohle nedefinované chování může být úplně ukradené. Není to nedefinované chování ve významu z C/C++.

Všechny implementace při volání error provedou něco, podle čeho můžeš identifikovat, co máš v programu špatně. A žádná ani v principu nemůže provést něco, co bys chtěl aby se stávalo u zákazníka. Jestli při volání error program vypíše něco do konzole, segfaultuje, nebo zatuhne a zabije ho watchdog je na zákaznickém stroji +- putna. Není to úplně identické, ale nějaký zásadní rozdíl v tom není.

A to, že se na tu chybu nemusí přijít vždycky je naprosto normální ve všech programovacích jazycích, co znám. To vyhodnocení může přerovnat optimalizátor, plánovač vláken, nebo se třeba může změnit hashovací funkce pro kontejner callbacků. Jestli spoléháš na to, že ti zabugovaný kód vždycky zavolá panic, tak to raději nedělej.

Jo, XStrict může rozbít korektní lazy kód. Jenže :
- Když můj kód vyžaduje lazy vyhodnocení, tak xstrict samozřejmě nepoužiju. Úplně stejně nepoužiju -ffast-math, pokud vyžaduju striktní floatovou sémantiku.
- V praxi se takový kód vyskytuje minimálně. Já se s ním potkal jenom v ukázkových příkladech.

Re:Rychlost Haskell vs. C++
« Odpověď #143 kdy: 29. 08. 2018, 13:03:41 »
Hlavně pořád bychom rádi viděli případ, kdy lazy evaluation rozbije strict kód...

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #144 kdy: 29. 08. 2018, 13:58:13 »
Hlavně pořád bychom rádi viděli případ, kdy lazy evaluation rozbije strict kód...
Definuj rozbije. Dostaneš jiný výstup.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #145 kdy: 29. 08. 2018, 14:04:23 »
Všechny implementace při volání error provedou něco, podle čeho můžeš identifikovat, co máš v programu špatně. A žádná ani v principu nemůže provést něco, co bys chtěl aby se stávalo u zákazníka. Jestli při volání error program vypíše něco do konzole, segfaultuje, nebo zatuhne a zabije ho watchdog je na zákaznickém stroji +- putna. Není to úplně identické, ale nějaký zásadní rozdíl v tom není.
Sorry, ale jsi úplně mimo. Vůbec nemáš ponětí o řízení kvality a o tom, jak nasazovat a provozovat aplikaci u zákazníka. Pokud aplikace u zákazníka spadne, tak chci sakra co nejrychleji a co nejpodrobněji vědět, co se stalo a proč. Protože zákazník na mě bude řvát, že mu to nefunguje a že mi nezaplatí. Zákazníka vůbec nezajímá, že ty si myslíš, že je +- putna co to dělá na jeho stroji. On chce, aby to fungovalo.

A to, že se na tu chybu nemusí přijít vždycky je naprosto normální ve všech programovacích jazycích, co znám. To vyhodnocení může přerovnat optimalizátor, plánovač vláken, nebo se třeba může změnit hashovací funkce pro kontejner callbacků. Jestli spoléháš na to, že ti zabugovaný kód vždycky zavolá panic, tak to raději nedělej.
Panic není žádná magie. V normální jazycích (mimo Haskell) se chová deterministicky.

JSH

Re:Rychlost Haskell vs. C++
« Odpověď #146 kdy: 29. 08. 2018, 14:57:40 »
Všechny implementace při volání error provedou něco, podle čeho můžeš identifikovat, co máš v programu špatně. A žádná ani v principu nemůže provést něco, co bys chtěl aby se stávalo u zákazníka. Jestli při volání error program vypíše něco do konzole, segfaultuje, nebo zatuhne a zabije ho watchdog je na zákaznickém stroji +- putna. Není to úplně identické, ale nějaký zásadní rozdíl v tom není.
Sorry, ale jsi úplně mimo. Vůbec nemáš ponětí o řízení kvality a o tom, jak nasazovat a provozovat aplikaci u zákazníka. Pokud aplikace u zákazníka spadne, tak chci sakra co nejrychleji a co nejpodrobněji vědět, co se stalo a proč. Protože zákazník na mě bude řvát, že mu to nefunguje a že mi nezaplatí. Zákazníka vůbec nezajímá, že ty si myslíš, že je +- putna co to dělá na jeho stroji. On chce, aby to fungovalo.
No právě proto, že to potřebuju co nejrychleji vědět, tak musí error handler posbírat zbytky a poslat mi je. A je celkem jedno, jestli ten program něco vypíše do konzole, segfaultuje, nebo jak konkrétně umře. Prostě umře a dostanu zbytky. V tom crashdumpu se bude lišit jak přesně umřel a to je tak všechno.
Prakticky je ten error dostatečně dobře definovaný i v haskellu. V kontextu funkcionálního programování ta nedefinované hodnota znamená jenom to, že ta funkce nevrátila hodnotu a stalo se něco jiného.
Citace
A to, že se na tu chybu nemusí přijít vždycky je naprosto normální ve všech programovacích jazycích, co znám. To vyhodnocení může přerovnat optimalizátor, plánovač vláken, nebo se třeba může změnit hashovací funkce pro kontejner callbacků. Jestli spoléháš na to, že ti zabugovaný kód vždycky zavolá panic, tak to raději nedělej.
Panic není žádná magie. V normální jazycích (mimo Haskell) se chová deterministicky.
I ten error není žádná magie a chová se deterministicky. Jen se díky rozdílu strict vs lazy může ta chyba detekovat malinko jindy. V praxi je to srovnatelné s nedeterminismem z jiných zdrojů. Že se půl programu neprovede je možné jenom v syntetických ukázkách odtržených od reality.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #147 kdy: 29. 08. 2018, 15:57:29 »
No právě proto, že to potřebuju co nejrychleji vědět, tak musí error handler posbírat zbytky a poslat mi je. A je celkem jedno, jestli ten program něco vypíše do konzole, segfaultuje, nebo jak konkrétně umře. Prostě umře a dostanu zbytky. V tom crashdumpu se bude lišit jak přesně umřel a to je tak všechno.
Tak zaprvé crashdump ti typicky nikdo nedá, protože v tom můžou být citlivá data (šifrovací klíče, data z databáze...) a zadruhé těžko něco dostaneš, když je chování error nedefinované a může skončit v nekonečné smyčce...

Prakticky je ten error dostatečně dobře definovaný i v haskellu. V kontextu funkcionálního programování ta nedefinované hodnota znamená jenom to, že ta funkce nevrátila hodnotu a stalo se něco jiného.
Kde "něco jiného" může být "cokoliv".

I ten error není žádná magie a chová se deterministicky. Jen se díky rozdílu strict vs lazy může ta chyba detekovat malinko jindy. V praxi je to srovnatelné s nedeterminismem z jiných zdrojů. Že se půl programu neprovede je možné jenom v syntetických ukázkách odtržených od reality.
Jak deterministicky? Je zaručeno, že error neskončí v nekonečné smyčce? Je zaručeno, že ukončí program a vypíše smysluplnou chybu na výstup?

v

Re:Rychlost Haskell vs. C++
« Odpověď #148 kdy: 29. 08. 2018, 16:10:50 »
https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-230003.1
Citace
A call to error terminates execution of the program and returns an appropriate error indication to the operating system.

Re:Rychlost Haskell vs. C++
« Odpověď #149 kdy: 29. 08. 2018, 19:46:55 »
Všechny implementace při volání error provedou něco, podle čeho můžeš identifikovat, co máš v programu špatně. A žádná ani v principu nemůže provést něco, co bys chtěl aby se stávalo u zákazníka. Jestli při volání error program vypíše něco do konzole, segfaultuje, nebo zatuhne a zabije ho watchdog je na zákaznickém stroji +- putna. Není to úplně identické, ale nějaký zásadní rozdíl v tom není.
Sorry, ale jsi úplně mimo. Vůbec nemáš ponětí o řízení kvality a o tom, jak nasazovat a provozovat aplikaci u zákazníka. Pokud aplikace u zákazníka spadne, tak chci sakra co nejrychleji a co nejpodrobněji vědět, co se stalo a proč. Protože zákazník na mě bude řvát, že mu to nefunguje a že mi nezaplatí. Zákazníka vůbec nezajímá, že ty si myslíš, že je +- putna co to dělá na jeho stroji. On chce, aby to fungovalo.

Naopak, jde vidět, že ví, o čem mluví. Zatím jsi mimo spíš ty - minimálně co se Haskellu týče nás o tom přesvědčuješ celé vlákno.

Hlavně pořád bychom rádi viděli případ, kdy lazy evaluation rozbije strict kód...
Definuj rozbije. Dostaneš jiný výstup.

Ne, chci vidět příklad kódu, který funguje korektně ve strict režimu a jeho vypnutím (tj. "s výchozím" lazy evaluation) přestane fungovat (obávám se, že to není možné). Zatím jsi ukázal kód, který 1) to měl obráceně 2) nebyl funkční.

https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-230003.1
Citace
A call to error terminates execution of the program and returns an appropriate error indication to the operating system.

Někomu se tu teď zhroutil svět  :o