Re: Misc. questions and bugs

From: Erick Gallesio <Erick.Gallesio_at_unice.fr>
Date: Sat, 5 Jun 1999 14:46:55 +0200 (CEST)

Ben L. Di Vito writes:
>
> - Is there a direct way to extract the lambda arguments of a procedure?
> I know I can apply procedure-body and then take the cadr of it, but I
> was concerned about possible overhead with large procedures. Is the
> value returned by procedure-body already lying around as the value of
> the lambda, or does it have to be reconstructed from an internal
> form?

No the lambda form is here and doesn't have to be reconstructed. So it
does not cost.

>
> - I noticed that applying force to non-promise values just returns the
> value. This is good. I like that convention, but it differs from
> other Schemes that produce an error in this case. Can we assume the
> STk convention will work for all non-promise values?

Yes.

>
> - When an error occurs and report-error is invoked, what kind of
> continuation is in effect? Is it the same as if we had returned to
> the top level and then called report-error, or are we deeply nested
> at the point where the error occurred?

The continuation is the point where the error occurs (more or less)
but don't rely on this, because the handling of errors is something
which probably should be changed.

> If an error occurs within
> a Tk event handler, is a TclRelease or other necessary Tk cleanup
> performed before calling report-error?
>
You generally don't have to worry here with Tk cleanup.

> And now for a few bugs I ran into recently. These occurred in 3.99.4
> on a Linux box.
>
> - (list-tail '() 0) ==> error: bad list
>
Corrected. Thanks

> - (bind w <event>) produces an error when a nonnull binding exists.
> A null binding returns "" as the value. In Tcl/Tk this form gives
> the bindings that are in effect for the event. Is this form of the
> bind procedure implemented in STk?
>
This is also the case in STk:

    STk> (pack (button '.b))
    ()
    STk> (bind .b "<Enter>" (lambda () (display "Enter!\n")))
    ()
    STk> (bind .b "<Enter>")
    #[closure arglist=() 4021c2bc]
    STk>

Or perhaps I have not understood your problem.


> - STklos objects do make the procedure? predicate true, however.
>
> (procedure? (make obj)) ==> #t
>
> I don't know if this makes sense with respect to the internal
> representation, but it seems inconsistent with Scheme semantics
> because you can't apply such an object as a procedure.
>

Yes generally, but there are some objects which are applicable:
descendants of the <method> class. As you said it was for
implementation reasons, and since nobody asked for that and since I'm
lazy, I have let is on my TODO list since a long time ;-)

This is corrected now, procedure? rturn #t only for descendents of
<method>.

> - Another predicate with a problem is continuation?. It doesn't
> seem to recognize continuations and always returns false.
>
> (call/cc (lambda (p) (continuation? p))) ==> #f
>

Oops, I didn't seen this one. In fact this is due to the introductions
of values in R5RS, and the current call/cc implementation is a
standard procedure which call the R4RS call/cc. Currently, it is defined as


    (define call-with-current-continuation ;; The R5RS one
      (let ((call/cc call-with-current-continuation)) ;; The R4RS one
        (lambda (proc)
          (call/cc (lambda (cont)
                     (proc (lambda l (cont (apply values l)))))))))

The "cont" herin saisfies the continuation? predicate. This should be
modified, but I will not do that for now, because I want to release
the 4.0 as soon as possible, but I place in on my TODO list.


> - A bigger continuation problem occurs with dynamic-wind. It fails
> to invoke the third thunk when a continuation is called. See the
> following code.
>
> [lines deleted]

Since the correction of this one is not immediate, I will defer it for
a while. I hope to be able to correct this one before releasing 4.0,
but perhaps a better thing would be to rethink the implementation of
continuation to take into account this bug and the previous one.


                -- Erick
Received on Sat Jun 05 1999 - 14:43:32 CEST