Am Mi., 7. Sept. 2022 um 03:46 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Tue, Sep 6, 2022 at 5:39 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> there cannot be an
>> implementation, portable or not, on every Scheme implementation that
>> is allowed by R7RS. (As I tried to explain earlier, even access to
>> something like "%true-promise" would not help.)
>
>
> I continue to find your explanation incomprehensible, but I'll add a warning saying that on an unusual implementation of Scheme promises, it is not possible to treat promises as thunks; however, no such implementations are known.

Wolfgang, have you understood my point? Maybe you can explain it
differently and better.

It should be more than a warning.  It should say that it only works
with an extended version of the R7RS semantics. With R7RS (small)
semantics alone, it does not make sense to specify a procedure that is
polymorphic in promises and non-promises because every value can be a
promise.

In any case, I strongly suggest writing a SRFI dealing exclusively
with lazy evaluation and combinators for promises instead of making
SRFI 235 polymorphic.

I imagine that Wolfgang could be in the mood to write such a SRFI.

>>  I would
>> suggest either making promises a disjoint type or making them
>> indistinguishable from ordinary values, which would mean implicit
>> forcing and probably a Haskell-like kernel for Scheme.
>
>
> IMO the second option would be extremely destructive to the Scheme effort: all existing Schemes would have to be not just modified but discarded.  The first option is feasible and indeed desirable.  At the same time, we should close off the "promise = result" and "promises are implicitly forced in certain cases" options.

I agree with you about all these points; it's far easier to implement
this for Schemes that would natively do implicit forcing, than the
other way round.

For SRFI 226, I can make all this mandatory.

> I don't feel very strongly about "polymorphic `force`" as long as the other cases are suppressed.

I would remove it for two reasons: It's again some kind of ad-hoc
polymorphism that is not really needed and, secondly, there would be
no consistent logic:

A promise is a Scheme value like any other, so if force were
polymorphic, `(force (make-promise 'foo))` would be justified to
return `foo` as much as a promise promising `foo`.

Without polymorphism, `force` would be forced :) to return `foo`.