Hi Noha,
You asked of one example where fluid-let is not suitable. Well, one
key component of redo-safe-variables is that it's composable with
delayed compilation. Consider a two pass compiler, where in the first
pass closures are created and then in the next pass they will be
evaluated with argum
can piggy pack ontop
of parameter implementations or fluid implementations. In guile the
native fluid implementation was mutated to include redo safe variables
and redo safe parameters. As a result we could get a speedup of 10x or
more compared to using dynamic wind. Therefore we do not expect that
> 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 t
> Daniel Writed
> 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
>
On 1 April 2013 05:16, Stefan Israelsson Tampe 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
> t
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.
2. You shouldn't specify the semantics in terms of code, but b
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
Hi all,
Let's try to change the focus from the dynamic wind towards call/cc
and prompt semantics. I read the sorces of my guile-log and eralize
that one relly need to patch these constructs as well in order to get
the right behavior. Here is a new try at a spec.
==
Yeah, they are different for sure, The last attempt failed though the
previous one was better.
The reson I have a hard time trying to code it is that In one end I
wouldl like to build the
spec on what's already there. And on the other hand make sure that it
play well with dynamic states.
The issu
On Wed, Mar 27, 2013 at 5:44 PM, Noah Lavine wrote:
>
> Since it's definable with such a simple macro, I don't think it's
> appropriate for a SRFI.
>
>
Sorry, I just realized that that's not a sensible objection. If it's a
better interface than parameters, then it certainly should be a SRFI.
Howev
Hello,
On Wed, Mar 27, 2013 at 12:15 PM, Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:
> Hmm, your really are right in the sense that the common ideom in
> computer language design is to type a variable at the declaration of
> the variable. So basically a user would then do something
I have tried to change the cocnpet to use parameters and put it into a
state where one could code it directly into scheme using parameters
and dynamic-wind. This way we can just write library code and argue for
a design. The previous spec seamed to worked but is not sound I would
say. So here is an
On Wednesday, March 27, 2013 11:29:39 AM Noah Lavine wrote:
> On Wed, Mar 27, 2013 at 11:04 AM, Stefan Israelsson Tampe <
>
> stefan.ita...@gmail.com> wrote:
> > Hi Noha,
> >
> > On Wed, Mar 27, 2013 at 3:29 PM, Noah Lavine
> > >
> > wrote:
> > > Hello,
> > >
> > >
> > > On Wed, Mar 27, 2013 a
On Wed, Mar 27, 2013 at 11:04 AM, Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:
> Hi Noha,
>
> On Wed, Mar 27, 2013 at 3:29 PM, Noah Lavine
> wrote:
> > Hello,
> >
> >
> > On Wed, Mar 27, 2013 at 9:22 AM, Stefan Israelsson Tampe
> > wrote:
>
> I don't understand the difference. If I
Hi Noha,
On Wed, Mar 27, 2013 at 3:29 PM, Noah Lavine wrote:
> Hello,
>
>
> On Wed, Mar 27, 2013 at 9:22 AM, Stefan Israelsson Tampe
> wrote:
>>
>> On Wed, Mar 27, 2013 at 1:42 PM, Noah Lavine
>> wrote:
>> > Hello,
>> >
>> > Let me see if I understand the point of set! and set~. I think the goa
Hello,
On Wed, Mar 27, 2013 at 9:22 AM, Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 1:42 PM, Noah Lavine
> wrote:
> > Hello,
> >
> > Let me see if I understand the point of set! and set~. I think the goal
> is
> > to have a variable that is redo-safe, exc
On Wed, Mar 27, 2013 at 1:42 PM, Noah Lavine wrote:
> Hello,
>
> Let me see if I understand the point of set! and set~. I think the goal is
> to have a variable that is redo-safe, except that if someone uses set~ on
> it, then it is not redo-safe. Is that right?
No that would be hard to reason ab
Hello,
Let me see if I understand the point of set! and set~. I think the goal is
to have a variable that is redo-safe, except that if someone uses set~ on
it, then it is not redo-safe. Is that right?
If so, I think a variable like that is too hard to think about. I really
don't think they should
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
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.
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.
Als
On Tuesday, March 26, 2013 05:38:03 PM Noah Lavine wrote:
> Okay. Let me see if I understand this correctly:
>
> Let's say, hypothetically, that there were variables that worked
> exactly like fluids except that you could reference them by simply
> writing their names, instead of using (fluid-ref
Okay. Let me see if I understand this correctly:
Let's say, hypothetically, that there were variables that worked exactly
like fluids except that you could reference them by simply writing their
names, instead of using (fluid-ref ...). Would those be what you want?
I was confusing our fluids and
Yes, I think parameters and fluids are the same. I was wondering if
(with-redo-variables ...) could be a macro that expands to (with-fluids
...). Is that possible? It might not be.
Yeah, I had forgotten about the closure variables issue. That might turn
out to be a big problem with all of this, bu
Relly kind of you to answer this quickly,
good thoughts!
On Tuesday, March 26, 2013 02:05:41 PM Noah Lavine wrote:
> Hello,
>
> Two quick thoughts on this:
>
> 1. It's confusing to say "undo" and "redo", because those aren't in
> the Scheme standard, and I don't know of any SRFIs that have them
>
Hello,
Two quick thoughts on this:
1. It's confusing to say "undo" and "redo", because those aren't in the
Scheme standard, and I don't know of any SRFIs that have them either.
Instead, maybe you could say "using continuations to implement computations
that restart". Or, "using continuations to i
Dear friends,
1. I will change the name special variables to
redo-safe-variables. And the parameter semantic I'm using to redo safe
parameters. Itis clumsy but descriptive.
2. To implement these in a good way we need to touch the fundamentals
of scheme. If we want to. But the concept is difficul
26 matches
Mail list logo
