%JS-TRY Case

[vlad-km]

Function jscl::true-cons-p (location: src/types.lisp)

@davazp , mmm?

Stable version (2022-2025)

CL-USER>(jscl::true-cons-p (list 1 2))
NIL
CL-USER>(jscl::true-cons-p '(1 . 2))
T
CL-USER>

Last release

CL-USER> (jscl::true-cons-p '(1   2))
NIL
CL-USER> (jscl::true-cons-p (cons 1   2))
TYPE-ERROR: 2 is not a CONS.
    ....
... 61 more frames, increase JSCL::*BACKTRACE-LIMIT* to view more
T
CL-USER>

As far as I can see, the %js-try code hasn't changed. How can this behavior be explained - it prints the error type, but returns the correct return code?

The following code executes without error printing

(defun true-cons-p (form)
  (handler-case
      (progn
        (list-length form)
        (return-from true-cons-p nil))
    (error (msg)
           (return-from true-cons-p t)  )))

but this solution is poor in terms of both JS code size and execution time

CL-USER> (time (dotimes (i 100000) (true-cons-p '(2 .  1))))
Execution took 12.351 seconds

jscl::true-cons-p stable version performance

 CL-USER>(time (dotimes (i 100000) (jscl::true-cons-p '(1 . 2))))
Execution took 0.436 seconds.

[davazp]

That's odd. Throws a condition but still returns. I imagine this is invoking the REPL handler and then the catch is capturing it the error to recover from it.

It seems it was introduced at 989010a.

[davazp]

Definitely true-cons-p should not be written to use conditions though.

Another harder question is how js-try should interact with conditions. But that is also quite limited what we can do.

@vlad-km would changing true-cons-p work for you or is this just an instance of a bigger problem?

[vlad-km]

It seems it was introduced at 989010a.

Nice! Now it's clear where to look for the problem. I want to see how deep the rabbit hole goes.

@vlad-km would changing true-cons-p work for you or is this just an instance of a bigger problem?

true-cons-p is a special case (dirty hack), various solutions are possible.

The unusual behavior of %js-try here draws attention.

While in the stable version the (catch msg ...) clause received an error-condition (e.g., Error: CDR called on non-list argument), in the new release:

1. the REPL prints a Type-error
2. it executes the code and prints the execution result
3. In the (catch msg ...) clause, msg satisfies (%%nlx-p msg) => t, and the msg itself is 'BALL-OUT'