> 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.
>
You can if you have access to the primitive `%true-promise` procedure. The
only way a %true-promise could be a procedure is if the compiler can prove
that the body of the promise is without side effects (and in practice
running time counts as a side effect here).
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.
Indeed, R[57]RS has only two kinds of ad hoc polymorphism: between exact
and inexact numbers, and between I/O-able types.
> 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)?
>
More than that. There is no (or OBJ1 OBJ2), only (or <expr1> <expr2>), and
there is no guarantee that <expr2> evaluates to an object.
> I think implicit forcing is almost all that is needed.
>
The objection to pervasive implicit forcing is that it involves a novel and
extremely pervasive sort of polymorphism. Thus `string-set!` becomes
polymorphic in all three of its arguments, allowing for eight cases:
({string, %true-promise-of-string}, {exact integer,
%true-promise-of-exact-integer}, {character, %true-promise-of-character}).
A compiler may or may not be able to weed out some or all of this
polymorphism, but you certainly can't count on it.
