From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: noah.b.lavine@gmail.com, guile-devel@gnu.org
Subject: Re: redo-safe-variables and redo-safe-parameters
Date: Wed, 03 Apr 2013 21:36:45 +0200 [thread overview]
Message-ID: <26254241.alHDNf9hMe@warperdoze> (raw)
> Noha writes
> Hi,
> A few points:
> 1. I really, really think that it is a bad idea for the type of a
> variable to change depending on how it is used (i.e. set!
> vs. set~). That means that you should remove points 12 and 14, and
> maybe some other points.
I agree with you now, I was a bit too creative there :-)
> 2. You shouldn't specify the semantics in terms of code, but by a
> description. That means removing points 3, 4, 5, and 7 and replacing
> them with text that says how the variables work. You can move the
> same ideas down to the reference implementation, though - that is
> good.
I will in the end go there meanwhile I like to keep some code for
clarity.
> 3. I strongly suspect that you will find that MIT Scheme's fluid-let
> has the semantics you want. If it doesn't, I would be interested to
> see an example that shows the difference between that and the type
> of variables that you want.
I think that fluid parameters fluid-let are close in semantics. but I
do not want the backtracking feature of fluid -let in some
applications and it carries an overhead compared to just haveing
variables and an init value.
Note:
I have been going back to guile-log to try to implement the ideas in
actual code. I got it working and implemented in efficient C I
hope. The code for e.g. any-interleave got 8x faster (Now About 10x
slower
then a simple all in stead of 80). My conclusion now is that to get an
efficient implementation one needs to go back to dynamic-wind
guards. And demand that redo-safeness imply that we assume that the
code backtracks over the dynamic-wind at the state storage point. This
is featurefull enough to satisfy most uses of redo/undo that I can
think of.
/Stefan
next reply other threads:[~2013-04-03 19:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 19:36 Stefan Israelsson Tampe [this message]
2013-04-13 10:12 ` redo-safe-variables and redo-safe-parameters Stefan Israelsson Tampe
-- strict thread matches above, loose matches on Subject: below --
2013-04-04 21:13 Stefan Israelsson Tampe
2013-04-01 10:17 Stefan Israelsson Tampe
2013-03-26 17:40 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
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=26254241.alHDNf9hMe@warperdoze \
--to=stefan.itampe@gmail.com \
--cc=guile-devel@gnu.org \
--cc=noah.b.lavine@gmail.com \
/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).