2 ms·
> I am unsure where the proof, or even supporting argument You make a lazy function strict by asking for its output now rather than later. > An eager semantic
by mrkeen 2y ago
> I am unsure where the proof, or even supporting argument
You make a lazy function strict by asking for its output now rather than later.
> An eager semantics supports the expected semantics of types (for example, the natural numbers are the natural numbers).
What a (counter)example! In lazy semantics the natural numbers are the natural numbers. In eager semantics the natural numbers are stack overflow.
> moreover, admits definition of the lazy forms of these types using suspension types
This is the required modification that your library maintainer would need to make if he had produced a strict library that you wanted to use lazily. Hence "You cannot ask a strict function to behave lazily."
> There being no representation of the eager types in a lazy language
Because the lazy representation is the same as the eager representation in the source code. It's up to the caller to demand values now, or later, hence "But you can ask a lazy function to behave strictly."
- eru 2y ago> You make a lazy function strict by asking for its output now rather than later. That doesn't mean you can evaluate the function strictly. Have a look at this example: f = head . map (2+) x = f [5, undefined] You can ask for x right away (it's 7), but if you evaluate f strictly, it still diverges. In any case, my suggestion is not to deal with arbitrary functions; but to restrict the set of untagged functions to those where any evaluation order works. 'Works' in the sense that any evaluation order takes a finite amount of time.