I think we're asking for confusion to change the meaning of the terms in
You are right. Confusion would arise (and, in fact, my redefinition even confused you on first read).
If no better term comes up, I will use the term "dynamic extent" if a native speaker can confirm that "current-dynamic-extend" is not too much of an abuse of language.
Yes, that's exactly what I meant. As you note later, it does require
I have thought about a few use cases. Requiring that "(delay (force ...))" is being expanded into (the semantic equivalent of) "(delay-force ...)" would help library writers because it would make code involving delay and force more composable.
For unrestricted composability, however, we would need to require that a Scheme system automatically detects an invocation of ’force’ in tail-context while evaluating ‘expression’ in ‘(delay expression)’.
Such a requirement may be viewed as analogous to the requirement of Scheme to have proper tail calls and seems to be necessary for properly supporting lazy programming (as proper tail calls are necessary for properly supporting functional programming).
With just the primitives the R7RS gives us, it is not possible to implement such a requirement. I am currently thinking about what the right primitive concepts are to implement ‘(delay (force ...))’ without the crook ‘delay-force’ or its incarnations ‘stream-lambda’ or ‘stream-let’ in SRFI 41.