From: "Vítor De Araújo" <vbuaraujo@sapo.pt>
To: guile-user@gnu.org
Subject: Re: dynamic-wind
Date: Sun, 9 Jul 2017 11:09:25 -0300 [thread overview]
Message-ID: <59623915.6070104@sapo.pt> (raw)
In-Reply-To: <20170709135921.0f4890ad@bother.homenet>
On 09/07/2017 09:59, Chris Vine wrote:
> On Sun, 09 Jul 2017 00:34:13 +0300
> Marko Rauhamaa <marko@pacujo.net> writes:
>> 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.
>>
>> 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.
>
> I disagree with that. On the first point, you know that a
> dynamic-wind block can no longer be re-entered (if that is what you mean
> by "really final") when the continuation object concerned is no longer
> accessible. At that point it, and all references to other objects
> encapsulated by the continuation, will be released in the ordinary
> way. You also know the same when your continuation is only an escape
> continuation.
That helps the implementation know if a continuation will not be entered
again, but it does not help when you want to do the kinds of things you
do with unwind-protect or try/finally in other languages. For example,
with unwind-protect, you can open a port or another resource and ensure
it will be closed if control escapes the unwind-protect form. You can do
that with dynamic-wind, but it is less meaningful to do so because
control can be re-entered again. There is no language construct (as far
as I know – maybe there is in Guile) that can detect that flow has
exited the form and *will never enter it again*. So the presence of
continuations make operations like unwind-protect less meaningful. I
don't know what is the Scheme way to address these situations.
> Secondly, this is something of an irrelevance. I have found it very
> rare that one would want to use dynamic-wind when implementing
> co-operative multi-tasking with coroutines (at any rate,
> https://github.com/ChrisVine/guile-a-sync only does so for thread pool
> thread counts, and that is to cater for exceptions in local code rather
> than for jumps via continuation objects). Jumping out of a
> dynamic-wind block using a coroutine is generally inimical to the kind
> of asynchronous programming that coroutines are used for: you generally
> don't want to unset the state of the continuation, and then set it up
> again when you re-enter. You normally want to leave it just as it was
> at the time you yielded.
>
> I may be mistaking you for another poster, but I think you have
> previously said that you prefer the inversion of control ("callback
> hell") style of asynchronous programming to using coroutines. You
> would not usually think of using dynamic-wind there either, I hope.
>
> Scheme's continuations are very useful. Guile's delimited
> continuations are even more so. Dynamic-wind not so much, because it
> is a very blunt instrument.
>
> Chris
>
--
Vítor De Araújo
https://elmord.org/
next prev parent reply other threads:[~2017-07-09 14:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-09 12:59 dynamic-wind Chris Vine
2017-07-09 14:09 ` Vítor De Araújo [this message]
2017-07-09 14:49 ` dynamic-wind Chris Vine
2017-07-17 10:04 ` dynamic-wind Catonano
-- strict thread matches above, loose matches on Subject: below --
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 ` dynamic-wind David Kastrup
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=59623915.6070104@sapo.pt \
--to=vbuaraujo@sapo.pt \
--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).