unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: redo-safe-variables and redo-safe-parameters
Date: Wed, 27 Mar 2013 08:13:46 +0100	[thread overview]
Message-ID: <5150614.XCd6n4rqTv@warperdoze> (raw)
In-Reply-To: <CA+U71=PXBHH=R1CNHuUJtJLFDhcy-8ydrjwFRcVFzgnBwUybTw@mail.gmail.com>

On Tuesday, March 26, 2013 06:36:46 PM Noah Lavine wrote:
> Okay. I don't see a use for number 1. Could you explain why it's
> important? It seems easier to me to just let each variable have its
> own type.
Actually it has it's uses.
1. 

Note. This ideom aims at being a sound extension to the case where we
have non boxed local variables that are never put into a closure and
where we mutate them with lexical-set directly. Maybe that is easier
to think of them this way. As you see this ideom will enable pretty 
fast execution of the code in the common case where the variable is 
never put in a closure. It will in the not uncommon case when you put
a local variable inside a closure and return it and preserve the redo 
safe 
property. 

I didn't see that fluid-let could allow this as well through an
optimization e.g.

(let ((a 1)) code ...)

redo safe and can be well optimized =>
(let (a)
  (fluid-let ((a 1)) code ...))

And it's actually better in many ways in that fluid-let guards the
outer context of the variable to be changed. On the other hand, 
fluid-let does not mix well with delayed computations, my suggestion
does so indeed. So Different notions, different benefit. But as you
say thay are close to my number 2 suggestion


> As for 2, I believe that's how MIT Scheme's (fluid-let ...) works. I
> suspect that if you give up property 1, then fluid-let would do the
> job you want.

No, parameter values are stored in different dynamic state and because
you have one dynamic state per thread usually (it's possible to let
threads share dynamic-state) the concpet is safe with respect to 
multithreading. It does not look like fluid-let have that property.


a)
> Also, in the example you gave earlier (in your third email in this
> thread, beginning with "you need to combine fluids and dynamic wind
> ..."), I don't see the difference between set! and set~ semantics. 

b)
>It
> seems like the variables there have exactly the same semantics as
> fluids, except that you don't have to use (fluid-ref ...) to get
> their value.

a)
set! means that you will box a value. The coders intention is that it 
should
behave as such. With set~ you will many times be able to unbox the
value. But as you say, with the example it may look like they are the
same. But note that putting a set! in the code means that the
variables becomes unguarded and the with-undo-variables becomes a
no-op. Really The whole setup is done in order to keep ~ semantic
enclosed in a macro and the user of the macro should can work as if
the macro only uses local variables with no set!.

b)
As I said, you are right that they are close in notion and many times
the semantic will overlap but as described above they are different.

/Stefan




  reply	other threads:[~2013-03-27  7:13 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 [this message]
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
  -- 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=5150614.XCd6n4rqTv@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).