4 ms·

Why would laziness be "unpredictable"? Also I'm pretty sure Ferret is strict, since it is not mentioned on their web page. edit: it's mentioned in the "overvi

• nine_k 4y ago
  It's not "unpredictable" as in "stochastic", but rather as in "hard to reason about". This may be compiler-specific. Say, Haskell does not give you much heads-up on laziness: whether stream fusion actually kicks in where you expect it to, or are you encountering quadratic behavior due to laziness [1]. If Ferret dives you decent visibility into issues like these, laziness may be usable even in hard-realtime setting, because it would become obvious and predictable for the developer. [1]: https://accidentallyquadratic.tumblr.com/post/114149142587/revisiting-haskell-network-http https://accidentallyquadratic.tumblr.com/post/114149142587/r...
  • dllthomas 4y ago
    > whether stream fusion actually kicks in where you expect it to An aside, but I remembered seeing something that let you test for that, likely https://hackage.haskell.org/package/inspection-testing https://hackage.haskell.org/package/inspection-testing
• code_biologist 4y ago
  A good dive into of why lazy IO is a problem are these Oleg slides: https://okmij.org/ftp/Haskell/Iteratee/IterateeIO-talk-notes.pdf https://okmij.org/ftp/Haskell/Iteratee/IterateeIO-talk-notes... My favorite slide: I can talk a lot how disturbingly, distressingly wrong lazy IO is theoretically, how it breaks all equational reasoning. Lazy IO entails either incorrect results or poor optimizations. But I won’t talk about theory. I stay on practical issues like resource management. We don’t know when a handle will be closed and the corresponding file descriptor, locks and other resources are disposed. We don’t know exactly when and in which part of the code the lazy stream is fully read: one can’t easily predict the evaluation order in a non-strict language. If the stream is not fully read, we have to rely on unreliable finalizers to close the handle. Running out of file handles or database connections is the routine problem with Lazy IO. Lazy IO makes error reporting impossible: any IO error counts as mere EOF. It becomes worse when we read from sockets or pipes. We have to be careful orchestrating reading and writing blocks to maintain handshaking and avoid deadlocks. We have to be careful to drain the pipe even if the processing finished before all input is consumed. Such precision of IO actions is impossible with lazy IO. It is not possible to mix Lazy IO with IO control, necessary in processing several HTTP requests on the same incoming connection, with select in-between. I have personally encountered all these problems. Leaking resources is an especially egregious and persistent problem. All the above problems frequently come up on Haskell mailing lists.
• Joker_vD 4y ago
  > Why would laziness be "unpredictable"? Well, it's an empirical observation that Haskell programmers, however experienced they may be, are constantly surprised by the memory footprint of their programs — IIRC sometimes even the GHC's core developers get blindsided.
  • rowanG077 4y ago
    Memory footprint doesn't have much to do with realtime though.
    • otabdeveloper4 4y ago
      Of course it does, asymptotic memory behavior is the #1 reason for temporal instability.
      • rowanG077 4y ago
        That's only for long running programs generally with a GC. Ferret does not have a GC by default and furthermore can run without heap allocation if you want. One of the ways to get lower latency is in fact to never deallocate and just ensure you won't run out of memory until the task is done.
        • otabdeveloper4 4y ago
          You just described practical examples of how to lower temporal instability by controlling memory allocation behavior :)
          • rowanG077 4y ago
            Yes I am. And the ones I'm referencing clearly show that ballooning memory is not equal to higher latency, as you claimed. You might say there is a correlation but those are due to other factors and not amount of memory used.