[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Some comments after reading the r7rs public draft
On Sun, Jun 10, 2012 at 9:57 AM, Ray Dillinger <bear@x> wrote:
> Scheme's "delay" and "force" have never really made strong enough
> guarantees that delayed promises will not be computed unless
> forced. The language allows implicit forcing whenever a promise
> is referred to.
If this were true it would definitely make delay
completely unusable, however it is not true.
What RnRS allow is "implicit forcing" when passing
a promise to a primitive "like `cdr' and`+'", with the
(+ (delay (* 3 7)) 13) => 34
given. This is obviously vague, but the intent is that
primitives which immediately need the actual value
are allowed to do an implicit force. Other primitives
like "cons" for instance, don't care what the value is
and should not perform an implicit force - otherwise
you couldn't build a stream.
Probably we should clarify this definition as you suggest.
Chibi-scheme allows implicit forcing as a compile
time option (probably eventually to be a language-level
option), and has a formal definition of which primitives
can and can't perform implicit forcing.
> This makes it impossible to do anything else
> with a promise. You can't even portably write a function to
> tell whether something is a promise or not, because you can't
> reliably pass it unevaluated as an argument to such a function.
You couldn't portably write a function to do this
even if there were no implicit forcing - promises may
not even be a disjoint type. We could consider changing
> For that reason, I have never found these primitives very useful.
> If you have a promise that will cause a side effect when forced,
> in Scheme you usually have something that will produce inconsistent
> behavior across different implementations, and sometimes even
> across different runs in the same implementation.
This is also untrue. One of the other extensions allowed is
pre-computation, e.g. (eqv? (delay 1) 1) => <unspecified>,
but this is only allowed when "there is no means by which a
promise can be operationally distinguished from its forced value."
If you find a case where a correct program would behave
differently whether or not this pre-computation were in effect
then you would have found an operational difference, and
thus a bug in the compiler.
The discussion above about pre-computing in background
threads is essentially a more general case of this.
Delay/force are extremely useful for a wide variety of
applications, including but not limited to lazy streams.
If you have a useful program which can't be written because
of the current definition (assuming sane implicit forcing as in
Chibi, and no bugs in the compiler) then I'd like very much
to see it.
Scheme-reports mailing list