Alex Shinn <xxxxxx@gmail.com> schrieb am Do., 6. Juli 2017 um 15:58 Uhr:

I think we're asking for confusion to change the meaning of the terms in
the standard. When I first read the SRFI 154 proposal I thought it was
only requiring parameters to be preserved, which is easier to implement
efficiently but separates the dynamic env from its extent, causing worse
problems than it solves.

If you want to avoid "dynamic extent," perhaps invent a new term?

(No, nothing comes to mind at the moment.)

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
users to write exactly (delay (force x)) and nothing else, e.g. instead of

(delay (begin (display "They forced me to do it!") (force (it))))

you must write

(delay (force (begin (display "They forced me to do it!") (it))))

It's a little strange, but then again so is delay-force.

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.

Marc

--
Alex