guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dynamic-wind


From: David Kastrup
Subject: Re: dynamic-wind
Date: Sun, 09 Jul 2017 09:21:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Marko Rauhamaa <address@hidden> writes:

> Amirouche Boubekki <address@hidden>:
>
>> I consider dynamic-wind an advanced concept not required for usual
>> hacking.
>
> Hm. Python's try/finally has several uses in virtually every program.
>
> Trouble is, Scheme's continuations make it impossible to know when
> something is really final.

When there is no reference to it anymore, just like with memory
allocation.

> In fact, implementing coroutines and cooperative multitasking using
> continuations almost guarantee a repeated back-and-forth through
> dynamic-wind.
>
> I strongly suspect Scheme's continuations are more trouble than they
> are worth.

Depends on your architecture.  The basic idea is not to have different
memory allocation for heap and return stack.  Basically, you put your
return "stack" in the heap and never actually reclaim memory when
returning but only when garbage collecting.

When function calls are hardware-supported but garbage-collection isn't,
the trade-offs for that model are not exactly fabulous.

Now continuations are not actually pervasively used in Scheme
programming like garbage-collection data life times are, and their
actual use does not tie greatly into Scheme's call syntax.  Yet a lot of
core Scheme constructs have constraints on their implementation because
the standards prescribe semantics compatible with pervasive use of
continuations.

So for real-life implementations of Scheme on today's architectures,
I find the cost/benefit tradeoff of continuations in relation to the
programming language unconvincing.

This might change in future architectures: remember that in Fortran's
heydays, stuff like stack-local variables and addressing and recursion
came with heavy associated costs because the computer architectures were
not actually designed to do complex things like stack-relative
addressing (anybody remember COMPASS' RJI, return jump instruction, for
function calls?).

So it's conceivable that garbage collection will become more native
(which would also help the data handling speed of any sweeped
garbage-collecting language, and there are numerous of them by now) and
that procedure handling might be made more compatible with it
eventually.

It's probably worth mentioning that "ChickenScheme" does this sort of
garbage-collection on the stack without actually executing function
returns in C.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]