Dynamic environment and dynamic extent are not the same thing.

The latter refers to the before and after thunks of dynamic-wind,

while the former refers only to parameter bindings.  I believe you

intend for promises to be run in the dynamic extent of the time

that they were created, not the environment.

Exactly. However, in SRFI 155 I am using the definition of "dynamic environment" as given in SRFI 154 and not that the narrower one of the R7RS (it is another question to be adressed for SRFI 154 whether it is a good idea to reuse the same name).

The reason why I am not using the term "dynamic extent" is that "dynamic extent" is a property of a call to a procedure. Instead of saying, "(force p)" is run in the dynamic environment of the original call to delay or delay-force, I would have to say that the dynamic extent of "(force p)" is enclosed by the dynamic extent of the original call to delay or delay-force. Such a wording would make the dynamic extent itself a dynamic thing: Depending on whether p is ever forced or not, the dynamic extent of delay or delay-force is extended by the call (force p) or not.

Anyway, all this is debatable and if someone comes up with a better wording that is also applicable to SRFI 154, I will be grateful.

Why do you think it was a mistake? The power of the language is exactly the same - whether you write (delay (force ...)) or (delay-force ...). The only difference seems to me that (scheme lazy) would pollute the namespace by one identifier less.

Or do you think that we would not have to tell users of Scheme to write "delay-force" instead of "(delay (force ...))" because the Scheme system would take care of that itself?

 

In any case, an implementation of (scheme lazy) is free to write:

(define-syntax delay

  (syntax-rules (force)

    ((delay (force x))

     (delay-force x))

    ((delay x)
     ...)))

If you want, I can make this mandatory for the delay as exported by SRFI 155. Yes, maybe that's a good idea.