Hi, John!

Am Mo., 5. Sept. 2022 um 18:44 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Mon, Sep 5, 2022 at 2:31 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> 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.

This is not the case, I think. (Maybe my ad-hoc choice of the name
"%true-promise" was not the best.) The expression

(make-promise obj)

evaluates to a promise on which `%true-promise` wouldn't return `#t`.

In particular, if THUNK is a thunk, one cannot distinguish whether the value of

(make-promise THUNK)

is meant as a thunk or as a promise in the dynamic dispatch Wolfgang
had in mind.

>>
>> 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

"It" should have been something like "A".

>> (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.

The three disadvantages of ad-hoc polymorphism I mentioned only matter
in the presence of a dynamically-typed language.

I don't mean that ad-hoc polymorphism should be eradicated from
Scheme, but introducing new variants should only be done for very good
reasons.  Historically (with the introduction of fixnum and flonum
libraries and record types), Scheme has actually been moving away from
ad-hoc polymorphism towards stricter and more fine-grained dynamical
types. For good reasons, I'd say.

>> 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.

You mean because in a typical implementation where

(or OBJ1 OBJ2)

translates into something like

(let ((tmp OBJ1))
  (if tmp tmp OBJ2))

only OBJ1 will be forced but not OBJ2 (if the implementation supports
implicit forcing)?

If forcing OBJ2 has side effects (which is usually avoided), this
would make a difference if the result of the `or` expression is not
used. But I doubt that it would warrant the introduction of a
`lazy-or-promise`.  If I understood Wolf correctly, he wanted to
promote lazy evaluation (and algorithms) in Scheme, and for that goal,
I think implicit forcing is almost all that is needed.