bug#14039: Bug in with-fluids semantics

bug#14039: Bug in with-fluids semantics

[Stefan Israelsson Tampe]

Consider this simple exmple with fluids and reodos via propmts,

(define (f x) 
  (let ((s (make-fluid 0))) 
     (with-fluids ((s 0)) 
        (let lp ((i 0)) 
           (cond ((>= i 100) (fluid-ref s)) 
                 ((= i 50) (abort-to-prompt 'tag) (lp (+ i 1))) 
                 (else (fluid-set! s (+ (fluid-ref s) i)) 
		       (lp (+ i 1))))))))

(define k (call-with-prompt 'tag (lambda () (f 1)) (lambda (k . l)
k)))

Then we will get in guile-2.0 pretty resent git version
scheme@(guile-user)> (k)
$1 = 4900
scheme@(guile-user)> (k)
$2 = 8575

The reason is that when the with-fluid returns normally it does a full
swap. It should only do half a swap e.g. restore the old value of the
fluid and not store the current which is of non use because it can not
be reached anymore and it contaminates the continuation k.

/Stefan

bug#14039: Bug in with-fluids semantics

[Daniel Hartwig]

On 23 March 2013 18:41, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
> Consider this simple exmple with fluids and reodos via propmts,
>
> (define (f x)
>   (let ((s (make-fluid 0)))
>      (with-fluids ((s 0))
>         (let lp ((i 0))
>            (cond ((>= i 100) (fluid-ref s))
>                  ((= i 50) (abort-to-prompt 'tag) (lp (+ i 1)))
>                  (else (fluid-set! s (+ (fluid-ref s) i))
>                        (lp (+ i 1))))))))
>
> (define k (call-with-prompt 'tag (lambda () (f 1)) (lambda (k . l)
> k)))
>
> Then we will get in guile-2.0 pretty resent git version
> scheme@(guile-user)> (k)
> $1 = 4900
> scheme@(guile-user)> (k)
> $2 = 8575
>

What values do you expect from successive calls to K?

> The reason is that when the with-fluid returns normally it does a full
> swap. It should only do half a swap e.g. restore the old value of the
> fluid and not store the current which is of non use because it can not
> be reached anymore and it contaminates the continuation k.

K captures S, a fluid, along with the dynamic extent.  There is only a
single dynamic extent to which K resumes, and only one value
associated to the fluid S within that.  Subsequent calls to K do not
generate a new dynamic extent, so it makes sense that modifications to
the fluids value persist.  This example behaives as expected according
to my understanding of fluids.

Am I missing something?

bug#14039: Bug in with-fluids semantics

[Stefan Israelsson Tampe]

I would expect
(k) to be the same. Otherwise fluids would not mix well with undo redo sematics.
But I do understand that people might have decided that it should work
like this.
and knowing the this semantic, one can fix the problem. If the
semantics is correct
I really can't find an example where it is useful though. Do you have
an example?

/Stefan

On Sat, Mar 23, 2013 at 3:51 PM, Daniel Hartwig <mandyke@gmail.com> wrote:
> On 23 March 2013 18:41, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
>> Consider this simple exmple with fluids and reodos via propmts,
>>
>> (define (f x)
>>   (let ((s (make-fluid 0)))
>>      (with-fluids ((s 0))
>>         (let lp ((i 0))
>>            (cond ((>= i 100) (fluid-ref s))
>>                  ((= i 50) (abort-to-prompt 'tag) (lp (+ i 1)))
>>                  (else (fluid-set! s (+ (fluid-ref s) i))
>>                        (lp (+ i 1))))))))
>>
>> (define k (call-with-prompt 'tag (lambda () (f 1)) (lambda (k . l)
>> k)))
>>
>> Then we will get in guile-2.0 pretty resent git version
>> scheme@(guile-user)> (k)
>> $1 = 4900
>> scheme@(guile-user)> (k)
>> $2 = 8575
>>
>
> What values do you expect from successive calls to K?
>
>> The reason is that when the with-fluid returns normally it does a full
>> swap. It should only do half a swap e.g. restore the old value of the
>> fluid and not store the current which is of non use because it can not
>> be reached anymore and it contaminates the continuation k.
>
> K captures S, a fluid, along with the dynamic extent.  There is only a
> single dynamic extent to which K resumes, and only one value
> associated to the fluid S within that.  Subsequent calls to K do not
> generate a new dynamic extent, so it makes sense that modifications to
> the fluids value persist.  This example behaives as expected according
> to my understanding of fluids.
>
> Am I missing something?

bug#14039: Bug in with-fluids semantics

[Stefan Israelsson Tampe]

Ok, I've been meditating over this question and really I can't find a
single use case where the
current behavior is prefered with an optimized path and the more
natural behavior
where undo and redo works is dismissed as a faulty semantics with a
slow path. But not only this if my
suggested change to the VM op semantics is implemented we could
probably add a function
via the C wrapper framework to to the other half of the swap in order
to keep the current semantics.
Then we can force those who uses this semantics to change there code
to include the old behavior if they
wish. Or we might take the defensive route to do the otehr way around.

WDYT, can you find a use case where the current behavir is prefered?

/Stefan

On Sat, Mar 23, 2013 at 3:51 PM, Daniel Hartwig <mandyke@gmail.com> wrote:
> On 23 March 2013 18:41, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
>> Consider this simple exmple with fluids and reodos via propmts,
>>
>> (define (f x)
>>   (let ((s (make-fluid 0)))
>>      (with-fluids ((s 0))
>>         (let lp ((i 0))
>>            (cond ((>= i 100) (fluid-ref s))
>>                  ((= i 50) (abort-to-prompt 'tag) (lp (+ i 1)))
>>                  (else (fluid-set! s (+ (fluid-ref s) i))
>>                        (lp (+ i 1))))))))
>>
>> (define k (call-with-prompt 'tag (lambda () (f 1)) (lambda (k . l)
>> k)))
>>
>> Then we will get in guile-2.0 pretty resent git version
>> scheme@(guile-user)> (k)
>> $1 = 4900
>> scheme@(guile-user)> (k)
>> $2 = 8575
>>
>
> What values do you expect from successive calls to K?
>
>> The reason is that when the with-fluid returns normally it does a full
>> swap. It should only do half a swap e.g. restore the old value of the
>> fluid and not store the current which is of non use because it can not
>> be reached anymore and it contaminates the continuation k.
>
> K captures S, a fluid, along with the dynamic extent.  There is only a
> single dynamic extent to which K resumes, and only one value
> associated to the fluid S within that.  Subsequent calls to K do not
> generate a new dynamic extent, so it makes sense that modifications to
> the fluids value persist.  This example behaives as expected according
> to my understanding of fluids.
>
> Am I missing something?

bug#14039: Bug in with-fluids semantics

[Andy Wingo]

On Sat 23 Mar 2013 11:41, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> The reason is that when the with-fluid returns normally it does a full
> swap. It should only do half a swap e.g. restore the old value of the
> fluid and not store the current which is of non use because it can not
> be reached anymore and it contaminates the continuation k.

That's not how fluids work, semantically: for better (I think) or for
worse (you think).  We cannot change this.

A
-- 
http://wingolog.org/

bug#14039: Bug in with-fluids semantics

[Stefan Israelsson Tampe]

Well yes you can actually. You can change and keep at the same time :-)

I really agree that the current setup is what we got and may have merit
but the problem is I have not find any uses of it. I would be glad to
be wrong here
but you all keep throwing a theoretical argument against it and just don't buy
that until you can say that the semantic is good for this and that. On one side
I may be ignorant and then please give me a hint so that I can learn. Or this
is an indication of people being over theoretical in their argument.
Both things
can be right in my perspective so I'm not overly stupid being
persistent for the
good of the sake (Other than me might be glad to know about these matters)

But the problem is not what we have. My problem is that what I can see
as useful is
not possible in an effective way. The basic problem is that a swap
overwrites memory
that could be kept. And I would prefer that we find a solution where
both semantics can
co-exists in an effective manner.

So I would still consider it a BUG or at least a feature request.

/Stefan

On Sat, Mar 23, 2013 at 8:07 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Sat 23 Mar 2013 11:41, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
>> The reason is that when the with-fluid returns normally it does a full
>> swap. It should only do half a swap e.g. restore the old value of the
>> fluid and not store the current which is of non use because it can not
>> be reached anymore and it contaminates the continuation k.
>
> That's not how fluids work, semantically: for better (I think) or for
> worse (you think).  We cannot change this.
>
> A
> --
> http://wingolog.org/

bug#14039: Bug in with-fluids semantics

[Stefan Israelsson Tampe]

I got the impression (on irc) that you thought backtracking would be
compromised with
my fix. Not so. It's the other half of the swap that should be skiped.
All semantics referring
to situations where a continuation is used one or zero times is preserved.

Consider a fluid a, with value v and storage s

the swap used on wind and non local unwind and currently on return unwind
-------------
temp <- v
v  <- s
s  <- temp

Suggestion for the return unwind:
v <- s

E.g. we will backtrack to the old value before but not store the
current value in s.

It's true that the semantic is different. I would really say that we
need to have both implemented.
I would argue that my solution should be default. But I can live with
it being a separate construct
only that it will have support in the VM to get sane behavior in logic programs.

/Stefan



On Sat, Mar 23, 2013 at 8:07 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Sat 23 Mar 2013 11:41, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
>> The reason is that when the with-fluid returns normally it does a full
>> swap. It should only do half a swap e.g. restore the old value of the
>> fluid and not store the current which is of non use because it can not
>> be reached anymore and it contaminates the continuation k.
>
> That's not how fluids work, semantically: for better (I think) or for
> worse (you think).  We cannot change this.
>
> A
> --
> http://wingolog.org/