let definitions visible after error in gambit's gsi?

Question

While experimenting with gambit's gsi (4.6.6), I ran into an odd situation when I typed in something invalid inside let.

Doing it the normal way, everything is as expected. i andj are not visible.

> (let ((i 4) (j 3)) (display (+ i j)) (newline))
7
> i
*** ERROR IN (console)@2.1 -- Unbound variable: i
1> j
*** ERROR IN (console)@3.1 -- Unbound variable: j

However, if I flub up in the let block, i andj are visible. It's almost as if I'm still inside the scope of the let form. Is that what's going on? Also, looking at the numbers on the prompt e.g. >1> `2> etc. It looks like there's information there as well. If so, what is that? Maybe something related to nesting or an error mode?

2> (let ((i 2) (j 3)) (display + i j) (newline))
*** ERROR IN (console)@4.20 -- Wrong number of arguments passed to procedure
(display '#<procedure #2 +> 2 3)
3> i
2
3> j
3

This is a little different than in clojure. e.g.

user=> (defn display [n] (print n))
#'user/one-arg-function
user=> (let [i 2 j 3] (display + i j) (println))
ArityException Wrong number of args (3) passed to: user$one-arg-function clojure.lang.AFn.throwArity (AFn.java:437)

user=> i 
CompilerException java.lang.RuntimeException: Unable to resolve symbol: i in this context, compiling:(NO_SOURCE_PATH:0) 

user=> j
CompilerException java.lang.RuntimeException: Unable to resolve symbol: j in this context, compiling:(NO_SOURCE_PATH:0) 

Answer 1

This is a feature of Gambit's interactive debugger.

From the manual: http://www.iro.umontreal.ca/~gambit/doc/gambit-c.html#Debugging

A nested REPL is then initiated in the context of the point of execution where the evaluation was stopped. The nested REPL’s continuation and evaluation environment are the same as the point where the evaluation was stopped. For example when evaluating the expression ‘(let ((y (- 1 1))) (* (/ x y) 2))’, a “divide by zero” error is reported and the nested REPL’s continuation is the one that takes the result and multiplies it by two. The REPL’s lexical environment includes the lexical variable ‘y’. This allows the inspection of the evaluation context (i.e. the lexical and dynamic environments and continuation), which is particularly useful to determine the exact location and cause of an error.

In your case, the nested REPL started inside the let and thus had i and j bound.