unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: guile-user@gnu.org
Subject: Re: dynamic-wind
Date: Sun, 09 Jul 2017 09:21:18 +0200	[thread overview]
Message-ID: <8737a62hzl.fsf@fencepost.gnu.org> (raw)
In-Reply-To: 87r2xqmx4a.fsf@elektro.pacujo.net

Marko Rauhamaa <marko@pacujo.net> writes:

> Amirouche Boubekki <amirouche.boubekki@gmail.com>:
>
>> 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	other threads:[~2017-07-09  7:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-30 20:33 dynamic-wind Catonano
2017-06-30 21:48 ` dynamic-wind Panicz Maciej Godek
2017-07-02  6:00   ` dynamic-wind Catonano
2017-07-02  6:01     ` dynamic-wind Catonano
2017-07-02 11:58     ` dynamic-wind Chris Vine
2017-07-05  6:14       ` dynamic-wind Catonano
2017-07-05  8:23         ` dynamic-wind David Kastrup
2017-07-08 20:03         ` dynamic-wind Amirouche Boubekki
2017-07-08 21:34           ` dynamic-wind Marko Rauhamaa
2017-07-09  7:21             ` David Kastrup [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-07-09 12:59 dynamic-wind Chris Vine
2017-07-09 14:09 ` dynamic-wind Vítor De Araújo
2017-07-09 14:49   ` dynamic-wind Chris Vine
2017-07-17 10:04     ` dynamic-wind Catonano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8737a62hzl.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).