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

[Camm Maguire]

Hi Peter!

Peter Wood <address@hidden> writes:

> 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.
> 

Just a note here.  I'm not sure if the multiple-values fix I just
committed makes a difference, but I didn't get a segfault in the
*pretty-print* nil case, just an (apparently) endless stream of print
output to the terminal.  How long did it take you to segfault?

> (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
> 

OK, I'm assuming that everything that can be run should be printable,
so the existing behavior is not correct, right?  Is the correct
behavior here well defined, and if so, what is it?


> 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?
> 

GCL does have a separate type for *compiled* closures.  I haven't
looked at how they are printed, but I would guess similarly to what
you have above.  Of course we could come up with a scheme to
distinguish (lambda-closure from a cons, but I'd prefer not doing
anything too ad-hoc.  What happens in clisp/cmulisp?

> 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?  
> 

Embarrassingly enough, I am still too much of a lisp neophyte to
comment intelligibly.  But if more knowledgeable people can define
unambiguously what the correct behavior is, I'll see if it can be
implemented.

Take care,

> Regards,
> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah