4 ms·
> True || this_crashes(); That's not functional though--this_crashes() has side effects. I'm far from a Haskell expert, but I guess in practice you'd be retur
by zwegner 14y ago
> True || this_crashes();
That's not functional though--this_crashes() has side effects. I'm far from a Haskell expert, but I guess in practice you'd be returning some error type from that function, and it didn't matter whether it's evaluated or not, since True || arbitrary_expression will always just be True.
Laziness, AFAIK, only complicates compilation due to making it hard to reason about memory/performance, and for having branches all over to see if expressions have been evaluated yet.
- Tuna-Fish 14y agoConsider > True || construct_a_1TB_object() Unless you have infinite computation and memory, there are always visible side-effects, no matter how functional your language is.
- dllthomas 14y agoIf the 1TB object is constructed atomically, it has to wait, yes - but really, that's the case in eager languages too if you want the same final semantics. If the 1TB object can in any way be constructed a bit at a time, then in principle you can get some work done in constructing it and back that out if you wind up not needing it.