Funguje to i naopak. Pokud je kód v Haskellu napsaný s předpokladem strict evaluation, může ho lazy evaluation rozbít. Nebude to jenom pomalejší s lazy/strict evaluation, nemusí to vůbec fungovat.
Ne, bude to jenom pomalejší a může to mít brutálně větší nároky na paměť, ale fungovat to bude. Je to zhruba na stejné úrovni, jako když v C++ napíšeš rekurzivní funkci a spolehneš se na tail call optimalizaci, a pak to někdo přeloží bez optimalizace. Další "nevinný" switch, který "mění sémantiku"..?
Takže když něco poslepuješ dohromady, máš potenciální problém. Musíš vědět, s jakým předpokladem byl ten kód napsán a upravovat ho bang patterny podle toho, která část závisí na lazy a která na strict a taky podle toho, jestli to překládáš s XStrict, nebo ne.
Ano, Haskell není pro lepiče. Nadávání na lepiče, kteří pospojují kousky ze stackoverflow, jak zkompletují kód kterýmu nerozumí a on potom nefunguje je všude dost... ano, haskell pro takové lidi není.
Jinak:
- XStrict prakticky nikdo nepoužívá; to je prostě flag pro pokusy s výpočetními úlohami, je to naprosto okrajové
- Osobně jsem se za 5 let programování v haskellu nesetkal ani jednou se situací, kdy bych něco udělal strict a ono to přestalo fungovat. Popravdě mi připadá, že fakt, že se otáčíš na tomhle je spíš znakem, že jsi v tom neprogramoval, protože ta "změna sémantiky" prostě v praxi problém není. Kromě toho, že v praxi XStrict na "normální" kód prostě nikdo nepoužívá.
- Problém "lazy" evaluace jsou spíš memory leaky - stává se to zřídka. Ale u většího projektu se tak 1-2 povedou a je to strašná otrava to hledat.