unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Daniel Hartwig <mandyke@gmail.com>
To: guile-devel <guile-devel@gnu.org>
Subject: Re: redo-safe-variables and redo-safe-parameters
Date: Mon, 1 Apr 2013 09:37:08 +0800	[thread overview]
Message-ID: <CAN3veRe_Ekio1gkMeDD+gwjCqRm5AwJxc-EpgWjH9Uxu7SEidg@mail.gmail.com> (raw)
In-Reply-To: <CAGua6m3rGU6+X=7Pbs6LM_YLBoRGAa6KO08nivZW5_D7yRriMw@mail.gmail.com>

On 1 April 2013 05:16, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
> Note two things
> * it's better to pile up the redo-safe-variables with a parameter
> then the clumsy version in the previous mail which will not work well.
>
> * A continuation that backtracks from down the stack back to the creation of the
> continuation needs to restore the variable in order for redo and undo to
> be correct. This means that dynamic wind should be skiped for redo
> safe variables.
>
> e.g. you need to guard the state booth upwards and downwards. The reason to
> do this is that if we want to consider non-boxed variables that we
> local-set as an
> optimization for undo safe variables we need to add this complexity
>

Dynamic states are not suitable for the purpose.  They have nothing to
do with compenstating for the inability of continuations to backtrack
_through side-effects_.  I believe this will be obvious if you
consider the problem of side-effects generally, rather than focusing
only on variable assignment.

Backtracking is typically handled (at least, in part) by the
evaluator, by either:

- explicitly tracking side-effects, so that they can be reverted in a
sensible manner; or

- state-copying, that is, non-mutable environments.

Of course, in the absence of side-effects backtracking can be
trivially handled by continuations.  It seems you hope to abuse
dynamic states to avoid explicitly tracking the side-effects and the
result is quite a mess.

I do not see how you can hope to marry the concepts of continuations
and backtracking side-effects without modifying the evaluator, at
which point you have continuations and an evaluation environment that
is not Scheme, although perhaps very Scheme-like.


It seems your real objective is to extend Scheme-embedded logic DSLs
by supporting continuations and non-functional Scheme code within
them.  I appreciate that you have some experience in the area, can you
point to any papers that discuss anything similar to what you are
trying to achieve?  (Not the Scheme modifications, but the logic DSL +
side-effects + continuations).


Back to the Scheme modifications.  Perhaps I do not understand that
problem space as well as you, but when I look at this I see a
premature attempt to solve a problem that is _hard_.  There is also no
precedent for continuations that backtrack side-effects in any Scheme
or Lisp I know of, and noone will miss that if you do not acheive it.

Clearly you are spending some effort on this, and I do not like to see
anyone wasting efforts.  IMO this specific path is unproductive.

Regards



  parent reply	other threads:[~2013-04-01  1:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-26 17:40 redo-safe-variables and redo-safe-parameters Stefan Israelsson Tampe
2013-03-26 18:05 ` Noah Lavine
2013-03-26 20:43   ` Stefan Israelsson Tampe
2013-03-26 21:07     ` Noah Lavine
     [not found]       ` <CAGua6m0WyG2_Bk3+b8UDn6ee=mddmmaOPQiF9sJf+jYtE3LsgQ@mail.gmail.com>
2013-03-26 21:38         ` Noah Lavine
2013-03-26 22:01           ` Stefan Israelsson Tampe
2013-03-26 22:36             ` Noah Lavine
2013-03-27  7:13               ` Stefan Israelsson Tampe
2013-03-27 12:42                 ` Noah Lavine
2013-03-27 13:22                   ` Stefan Israelsson Tampe
2013-03-27 14:29                     ` Noah Lavine
2013-03-27 15:04                       ` Stefan Israelsson Tampe
2013-03-27 15:29                         ` Noah Lavine
2013-03-27 16:15                           ` Stefan Israelsson Tampe
2013-03-27 21:44                             ` Noah Lavine
2013-03-27 21:46                               ` Noah Lavine
2013-03-28  8:36                                 ` Stefan Israelsson Tampe
2013-03-27 21:37                       ` Stefan Israelsson Tampe
2013-03-28 18:03   ` Stefan Israelsson Tampe
2013-03-31 21:16     ` Stefan Israelsson Tampe
2013-04-01  1:23       ` Noah Lavine
2013-04-01  1:37       ` Daniel Hartwig [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-04-01 10:17 Stefan Israelsson Tampe
2013-04-03 19:36 Stefan Israelsson Tampe
2013-04-13 10:12 ` Stefan Israelsson Tampe
2013-04-04 21:13 Stefan Israelsson Tampe

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=CAN3veRe_Ekio1gkMeDD+gwjCqRm5AwJxc-EpgWjH9Uxu7SEidg@mail.gmail.com \
    --to=mandyke@gmail.com \
    --cc=guile-devel@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).