Yes, it's true, and the split is also painful in Haskell. The split exists in Haskell for a choice few data structures where it truly matters for performance --

Yes, it's true, and the split is also painful in Haskell. The split exists in Haskell for a choice few data structures where it truly matters for performance -- it also exists for Set/Map. (And I'd argue it is actually a bad thing from a purely language perspective, but sometimes practicality does win out, even in Haskell.) I think it might actually have been a mistake to have the lazy variants of these data structures, esp. Text/ByteString. IME it's extremely rare to want laziness for these... and it's usually just when building output strings (where there are better solutions like Builders). Anyway, I digress... IME the same applies to lazy Map/Set, but I'm less familiar with uses for the lazy versions of these. (IIRC they're only spine-lazy, which is rarely what you want, tho.) > And in LISP IIRC lazy data are type-compatible with strict data. LISP is dynamically typed -- it's trivial to do there. Also not the directionality: You can go from lazy to strict (that's just evaluation which the runtime will do for you), but you can NOT go the other way automatically. Recovering laziness from strictness is impossible. The problem with the split happens when you have mismatching types that your compiler will shout at you for.