Jim Rees <xxxxxx@gmail.com> schrieb am Mi., 4. Juli 2018 um 20:03 Uhr:
On Wed, Jul 4, 2018 at 11:42 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

One way to achieve this would be to specify that the dynamic extent of (srfi 154) is bounded in space by the set of continuation marks, parameterizations, and the installed dynamic-wind handlers.

What do you think about such a formulation?

So, the statement sounds true, but the "bounded-in-space" part doesn't really address the issue resolved by reduced-dynamic-extent, so it might be misleading.    I concur that the semantics implied by the term "dynamic extent" encompass continuation marks, parameters, dynamic wind handlers, and the exception handler (which could be implemented in terms of any of the prior three).  In the future, there might even be more distinct aspects of dynamic-extent.  It's up to (srfi 154) to aggregate all of these.

Yes, that's right. And (srfi 154) cannot predict the future. So better to leave out such a statement if it cannot be formulated future-proof.
 

3) One reason why I wrote (srfi 154) and (srfi 157) was to specify the necessary primitives so that (srfi 155) could be portably implemented on top of this.

To retain that, we will have export something like "reduced-dynamic-extent" in (srfi 154). I agree with you that "reduced-dynamic-extent" is not a pretty primitive and won't be used a lot. On the other hand, without such a procedure, dynamic extent objects are simply black boxes and one cannot do much with them except for reinstalling them.

Or would a procedure that captured the dynamic extent of the caller (and not the current one) be sufficient?

Are you asking if call-with-current-dynamic-extent solves all our problems and avoids the need for reduced-dynamic-extent? 

I was thinking of a procedure like "call-with-previous-dynamic-extent".

So it sounds like you want something like reduced-dynamic-extent in (srfi 154), so that (srfi 155) can be written portably - sounds good.

Another idea occured to me: What if the implementation of (srfi 155) attaches the dynamic extent prior to the evaluation of "with-continuation-mark" to the continuation mark added by this evaluation. Then the code called by with-continuation-mark can retrieve the dynamic extent and resurrect it, thus effectively deleting the just added continuation mark.

If this works, we don't need a procedure like "reduced-dynamic-extent". Could you check with your code?

Marc

 
 
4) Eventually, I think I will implement this in the Inferior Scheme system that I am using to demonstrate (srfi 157). Then, this can be added to (srfi 154) and (srfi 155) to have a sample implementation with correct space and time behavior.

When I have more time, I was going try to simulate your inferior scheme and see if I can prove everything over again in that model - but I'm pretty booked up for next 2-3 weeks.


To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=3gmIi49Ouh6YpCluDZXWeokz7NgY9f9r