Subject: Re: bug#14347: reset, shift, continuation values truncated inconsistently

From: Stefan Israelsson Tampe <[email-masked]>
Date: Mon, 6 May 2013 23:15:13 +0200

Hmm, we have

(let ((k (cal-with-prompt tag (-- expr that ends with (values a b c) --)
 (-- expr that is of unknown values length --))))
  (k))

So it looks like peval.scm in language/tree-il does not handle this well.

Looking in that file we have

(($ <prompt> src tag body handler)
       (define (make-prompt-tag? x)
         (match x
           (($ <application> _ ($ <primitive-ref> _ 'make-prompt-tag)
               (or () ((? constant-expression?))))
            #t)
           (_ #f)))

       (let ((tag  (for-value tag))
             (body (for-tail body)))

       ... cases where we can optimize sue to knowledge of prompt-tag ...

       (else
           (make-prompt src tag body (for-value handler))))))

So to me it looks like peval does a for-tail on body, and uses the value
constraint on the body. I'm not sure how to fix this though.

But that this is the problem can be shown by changing the code to

(($ <prompt> src tag body-in handler)
       (define (make-prompt-tag? x)
         (match x
           (($ <application> _ ($ <primitive-ref> _ 'make-prompt-tag)
               (or () ((? constant-expression?))))
            #t)
           (_ #f)))

       (let ((tag  (for-value tag))
             (body (for-tail body-in)))

       ... cases where we can optimize sue to knowledge of prompt-tag ...

       (else

   (make-prompt src tag (for-values body-in) (for-value handler))))))

/Stefan

On Mon, May 6, 2013 at 9:06 PM, Ian Price <[email-masked]> wrote:

> Jussi Piitulainen <[email-masked]> writes:
>
> > The documentation for reset and shift in the
> > manual does not quite say, but I believe the
> > captured continuation in these examples should be
> > the continuation of the shift expression inside
> > the reset expression, that is, it should simply
> > return the three values in all cases.
> Totally agree, this is the behaviour I expect
>
> > scheme@(guile-user)> (let ((k (reset (shift k k) (values 3.1 2 3))))
> (k))
> > $7 = 3.1
>
> scheme@(guile-user)> (import (only (rnrs) let-values))
> scheme@(guile-user)> (let ((k (reset (shift k k) (values 3.1 2 3)))) (k))
> $40 = 3.1
> scheme@(guile-user)> (let-values (((k) (reset (shift k k) (values 3.1 2
> 3)))) (k))
> $41 = 3.1
> $42 = 2
> $43 = 3
>
> So, my first suspicion was that there is some part of the code that
> receives the multiple values in a let or something, but neither the
> code, nor the ,expand command revealed that. However, when we check with
> ,optimize
>
> (let ((k (call-with-prompt
>            ((@@ (ice-9 control) default-prompt-tag))
>            (lambda ()
>              (apply abort
>                     ((@@ (ice-9 control) default-prompt-tag))
>                     (lambda (cont)
>                       (call-with-prompt
>                         ((@@ (ice-9 control) default-prompt-tag))
>                         (lambda ()
>                           (lambda vals
>                             (call-with-prompt
>                               ((@@ (ice-9 control) default-prompt-tag))
>                               (lambda () (@apply cont vals))
>                               (lambda (cont f) (f cont)))))
>                         (lambda (cont f) (f cont))))
>                     '())
>              3.1)
>            (lambda (cont f) (f cont)))))
>   (k))
>
> Gotcha. The optimizer is getting rid of the multiple values.
> On #guile, mark_weaver reminded me of
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13966 which I think is the
> same issue. But I haven't tested that yet.
>
> --
> Ian Price -- shift-reset.com
>
> "Programming is like pinball. The reward for doing it well is
> the opportunity to do it again" - from "The Wizardy Compiled"
>
>
>
>