[Gcl-devel] lambda-closure and *print-level*

[Peter Wood]

Hi

(let ((foo nil)) (setf foo (cons (lambda () 'x) foo)) foo)

results in an error if *print-pretty* is t, and a segfault if it is
nil.  If *print-level* is set to some lowish number, GCL prints the
result ok.

(setf *print-level* 2)
(let ((foo nil)) (setf foo (cons (lambda () 'x) foo)) foo)

=> ((LAMBDA-CLOSURE # () () () 'X))

In this case the second element of the cons has a print-level higher
than 2 so its replaced by #, and the result can print ok.  (This part
of the list represents the variable bindings at the time the closure
is established, eg 

>(let ((x nil) (y t)) (lambda () 'foo))

=> (LAMBDA-CLOSURE ((Y T) (X NIL)) () () () 'FOO)

so in the previous case, it can't be printed without 'infinite'
recursion)

Even in the error/segfault case, GCL is _not_ making any evaluation
errors since replacing 'foo with (funcall (car 'foo)) returns the
correct result. (ie X)  *print-<whatever>* is irrelevant here.

(let ((foo nil)) (setf foo (cons (lambda () 'x) foo)) (funcall (car
foo)))

=> X

I looked at the code in o/print.d, and it seems its a problem that GCL
represents the closure by a cons.  Is there any way the printer can
discern between an ordinary cons which happens to start with the
symbol 'lambda-closure, and a real closure object.  Presumably
x->c.c_car.s->st_self is the same for both objects?

(gdb) p  x->c.c_car.s->st_self
$2 = 0x8247931 "LAMBDA-CLOSURE"
(gdb) 

If the printer (write_object) could distinguish bewteen them, ...  Is
it still necessary to print a lambda-closure as a cons?  Could it not
be represented as an unreadable object, eg #<lambda-closure 0x8247931>.
Can we not dispense with printing the variable bindings environment?

I guess the same issues/questions apply to lambda-block-closures
since they also print as a cons with environment info.  What do people
think?  

Regards,
Peter