To nepochybuji že dělám plno věcí špatně, jsem konec konců začátečník. Ale když děláte IDE, musíte mít GUI, a takové i primitivní GUI pomocí gtk2hs je opravdu na hodně řádků kódu. A taky potřebujeme měnitelné reference pro komunikaci mezi handlery eventů. Výsledek je ten, že program je povětšinou jen tvořen IO monádou, a vlastně nevidíme rozdíl mezi psaním v C a Haskellu. U interpretru imperativního jazyka je tento problém stejný. Možná ale menší. Parser a serializer lze naštěstí udělat bez IO monády, částečně, měnitelné reference v ast jsou problém, ale samotný evaluátor už nejde udělat bez IO monády.
To je celkem známý problém, že IO je "virální". Záleží na typu řešeného problému, jak moc se to projeví. "v" srovnává nesrovnatelné - překladač je prakticky "batch processing", tam není problém. U interaktivnějších záležitostí, jako je právě to IDE, to problém je. Možná by mohl pomoct ten reaktivní přístup - oddělit věci, které provádí IO a pomocí něčeho na způsob channelů pak posílat do kódu, který už může být čistý. Ale chápu, že se to snadněji řekne, než udělá, jsem si toho vědom, nechci dávat knížečí rady, je to jenom poznámka na okraj, když už tady to reaktivní programování zaznělo...
Musím nesouhlasit. Není to jako IO monáda. Neumím to blíže vysvětlit. Musí se to zkusit.
Vždycky je to de facto variace na nějakou lambdu. Vytvoří se nějaké lambdy a ty se v runtimu spustí, čímž se provede to vlastní IO. Jak přesně je to uděláno je detail, ale vždycky je to něco na tenhle způsob, protože to ani jinak nejde