Re: redo-safe-variables and redo-safe-parameters

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

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 arguments and lead to the final code. If we would like
to have user interaction in this and in pass 1, store and then redo 
a state, the result would be as expected. Not so if the variables are 
backtracking.

No over to the general discussion:
----------------------------------

I have spend a lot of time in guile-log, thesting out the
redo-safeness properties and got it working with respect to user
interaction and the use-cases in described in the spec that I send to
the list. Then I spend time cleaning up guile-log and documenting. Now
I've come to the postpone logic and things get's really
interesting. The postpone module will let you store a set of states
representing choice points, then evaluate some heuritstic leading to
an index describing the liklihood of success in that branch and then
it will sieve out the most likly branches and continue with them. The
imlpementation was well tested and worked quite ok in the guile-unify
repo. But it has bitrotten quite a lot and need a rewrite.

So I read the code and analyzed the old behavior in the light of
redo-safe variables and parameters. My conclusion is twofold.

* The choice of doung the guard at the binding is not enough and the
  spec is well thought out for redo-safe-variables but not redo safe
  parameters. The reason is that the most effective way of storing
  the states is to keep a memory tree of the states and make sure not
  to keep duplicates in memory which would be the case if we stored a
  set of lists. Essentially you would use it like
 
     (let ((a 1))
         (any (with-redo-variables ((a 0)) (set~ a 2) P1)
              (with-redo-variables ((a 0)) (set~ a 3) P1)
              ...))

   In stead of

      (let ((a 1))
         (with-redo-variables ((a 0)) 
            (any (all (set~ a 2) P1) 
                 (all (set~ a 3) P2)
		  ...))) 
            
    The first is needed in the postpone because we do not backtrack
    over the guard when we store the state. Which we will do at a user 
    interaction use case and there the second form is enough.
    
    Conclusion:
    We need to add this postpone use case and decribe it in the spec
    and point at it for the rational behind the with-redo-variables
    guard. Also we need to change the semantics of redo safe parameters.
    
**  Another optimization is that it is much cheaper to reistate the
    same memory the second time e.g. we will reuse what we did
    before and hence cons much less. This can have a dramatic effect
    on the speed of any-interleave and hence is an important
    optimization. But note that the same guard will save a new state 
    everytime it backtracks which was assumed to be unclean but of any
    much high overhead. But in the light of the above optimization it
    will hinders the ability to reuse old infromation becase it is a
    linked list and it's not possible to exchange one element in the
    list. It's better to add a check and the unwind part of the guard 
    to actually store the state when in that mode e.g. that there is
    essentially two types do the abort, in a saving-state, mode, or
    keeping the state mode. This way only direct postpones will be
    affected but not ordinary uses of any-interleave.
    
    Conclusion: We need to ad a check in the unwind part as well.

/Stefan