On Thu, Jul 6, 2017 at 6:30 AM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Alex Shinn <xxxxxx@gmail.com> schrieb am Mi., 5. Juli 2017 um 17:21 Uhr:
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).

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.)

Have you run any benchmarks for this?  It seems an extremely
heavyweight operation for something which should be very
lightweight.  The dependence on dynamic-wind also means
performance will be highly variable per implementation.

The sample implementation won't perform well on implementations, for which call/cc is costly due to the presence of dynamic-wind. While I don't think that a Scheme implementation for which one of Scheme's main selling points is too slow to be used effectively is, in my opinion, a very decent one, I could change the sample implementation not to rely on call/cc in most use cases of forcing.

Yes, and correctness should be preferred above performance, but I was
worried that this would be too slow in practice (especially for streams),
that people might avoid the SRFI.  However, given the nice implementation
in

I have now provided special support for Chibi (just to have one demonstration target) in the sample implementation https://github.com/mnieper/srfi-154 of SRFI 154 (upon which SRFI 155 builds). This specific implementation uses the ideas outlined above. With it, SRFI 155 promises are very lightweight when parameterize and dynamic-wind is not used (so we don't have to pay for what we don't use) because the "travel-to-point!" I am using from (chibi) will be a no-op.

I don't think performance is as much of a concern.

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.

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.

-- 
Alex