4 ms·

In OCaml lazy data is fundamentally incompatible with strict data -- you have to explicitly evaluate it, e.g. when passing to a function which takes strict data

In OCaml lazy data is fundamentally incompatible with strict data -- you have to explicitly evaluate it, e.g. when passing to a function which takes strict data. This means you end up with two disjoint 'worlds' where you need to write algorithms twice, etc. (In fact you'd have to do that for every possible variant of where exactly the laziness lies.) The ergonomics become incredibly bad, unfortunately. (Also see my link to a Reddit thread elsewhere in this thread further ideas on why strict-by-default is not a simple win.)

Joker_vD 4y ago
The same split exists in Haskell as well: Data.Text.Text vs Data.Text.Lazy.Text, etc. And in LISP IIRC lazy data are type-compatible with strict data.
- Quekid5 4y ago
  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.

Joker_vD 4y ago

The same split exists in Haskell as well: Data.Text.Text vs Data.Text.Lazy.Text, etc. And in LISP IIRC lazy data are type-compatible with strict data.

Quekid5 4y ago
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.