Email list hosting service & mailing list manager

Reference to earlier thoughts by Marc Feeley Marc Nieper-Wißkirchen (02 Aug 2021 09:45 UTC)
Re: Reference to earlier thoughts by Marc Feeley John Cowan (02 Aug 2021 21:09 UTC)
Re: Reference to earlier thoughts by Marc Feeley Marc Nieper-Wißkirchen (03 Aug 2021 05:29 UTC)
Re: Reference to earlier thoughts by Marc Feeley John Cowan (04 Aug 2021 18:42 UTC)
Re: Reference to earlier thoughts by Marc Feeley Marc Nieper-Wißkirchen (04 Aug 2021 21:14 UTC)
Re: Reference to earlier thoughts by Marc Feeley Marc Feeley (04 Aug 2021 21:50 UTC)
Re: Reference to earlier thoughts by Marc Feeley John Cowan (04 Aug 2021 23:58 UTC)
Re: Reference to earlier thoughts by Marc Feeley Marc Nieper-Wißkirchen (05 Aug 2021 06:59 UTC)
Re: Reference to earlier thoughts by Marc Feeley John Cowan (05 Aug 2021 15:17 UTC)
Re: Reference to earlier thoughts by Marc Feeley Marc Nieper-Wißkirchen (05 Aug 2021 15:49 UTC)
Re: Reference to earlier thoughts by Marc Feeley Marc Nieper-Wißkirchen (05 Aug 2021 16:03 UTC)

Re: Reference to earlier thoughts by Marc Feeley Marc Feeley 04 Aug 2021 21:50 UTC

> On Aug 4, 2021, at 8:42 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
> On Tue, Aug 3, 2021 at 1:29 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> The whole (short) thread didn't end because Marc had changed his mind on what is the Right Thing; it ended because it had become clear that the Right Thing would have introduced an incompatibility with the R5RS ([1]).
>
> I meant that he had changed his mind about what SRFI 39 should contain.

Both of you are correct.  The semantically right thing is for the delay body to inherit the dynamic environment (similarly to what SRFI 18 threads do).  However, because R5RS has specified the meaning of (delay …) using a code equivalence, doing the semantically right thing in SRFI 39 would have been the politically wrong thing to do, so I dropped the issue.

But given that R7RS has introduced a dynamic environment in the semantics, it would have been good to clean-up the semantics of delay to behave well with parameters.  This would not have broken backward compatibility because R5RS did not have dynamic environments (except if current-input-port, etc are considered to be parameters, but that would have been a minor backward incompatibility).

To be clear, the right thing is for (delay <expr>) to have an effect on when <expr> is computed, and not what is being computed (when <expr> is side-effect free and terminates).  I believe this is what most programmers would expect and it is roughly how one explains the delay form to someone that does not know what it does.

Currently the delay form is broken for things like

    (define p (delay (display "foo")))

because the port on which foo is output is not clear… it depends on where the first call of (force p) is done, and this could depend on various factors not locally apparent.  A global understanding of the program is needed to know where foo will end up.

Ideally,

   (delay <expr>)
and
   (future <expr>) = (thread-start! (make-thread (lambda () <expr>)))

should both capture the dynamic environment so that <expr> is evaluated in the dynamic environment that was current when those forms were evaluated.

Marc