4 ms·

> RT necessitates laziness in some cases I would be interested to see your proof of that.

• pron 11y ago
  Any side effect must be lazily performed by the runtime at a level above the program's entry point (like main returning IO) or break RT. I don't mean that a PFP language must have non-strict evaluation.
  • tel 11y ago
    It's not lazy performance, it's a representation of that computation as a value. Most concretely by an interpreter. That's not really lazy evaluation and suffers from almost none of the ailments.
    • pron 11y ago
      > and suffers from almost none of the ailments. I'd say that's subjective, and that it suffers from enough ailments: no stack context for post-mortem debugging and profiling. I know Haskell has this "cost center" thing, but I don't know enough about them to tell whether they are truly sufficient. Anything that harms posthoc reasoning about a program with a debugger/profiler/log can be plenty painful.
      • tel 11y ago
        You can write an interpreter in any language. That's what I'm angling for here. There's no relationship to laziness except that if Haskell is your only example implementation then you're stuck with it.
• the_why_of_y 11y ago
  Lazy evaluation performs implicit side effects, which in some cases (and with RT as a premise) allows for better asymptotic complexity than eager evaulation. For an example see this paper: "More haste, less speed: lazy versus eager evaluation" by Richard Bird, Geraint Jones, Oege De Moor http://journals.cambridge.org/action/displayAbstract?aid=44113 http://journals.cambridge.org/action/displayAbstract?aid=441... ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Geraint.Jones/FP-1-96.ps.Z