On Mon, Sep 5, 2022 at 2:31 AM Marc Nieper-Wißkirchen <[email protected]> wrote:
> Another way would be where `make-promise` is just > > (define make-promise > (lambda (obj) obj)) > > and we would have something like > > (define promise? > (lambda (obj) #t)) > > (define force > (lambda (obj) > (if (%true-promise obj) (%true-force obj) obj))) > Fair enough. But that just means that this library needs some customization in the presence of such an unusual implementation of promises, and needs access to the %true-promise procedure. The very existence of such a procedure undercuts the claim that there is no operational method of distinguishing promises from the result of forcing them. > It better reason would be if it is expected that a procedure like > lazy-or-procedure wants to be called with a mixture of procedures and > promises. In the latter case, using a helper procedure > > (define promise->thunk > (lambda (obj) > (assert (promise? obj)) > (lambda () (force obj)))) > Yes, that can be done. Historically, though, ad hoc polymorphism first appeared around 1960 when Fortran programmers expressed their unwillingness to go on writing A + FLOAT(I) instead of A + I. At that time, + was already polymorphic but did not allow mixed-mode arithmetic. I tend to agree with you that promises are probably more interesting than > procedures. But when we want to make lazy evaluation more prominent in > Scheme, we have to go back to the basics and decide on whether to make > implicit forcing mandatory. In that case, something like ` > lazy-or-promise` would not be needed; one would just write `or`. > Not so, because `or` is not a procedure unless *everything* is lazy, as in Haskell.
