🚀 go-pugleaf

In article <NISINAKA.90Dec27030519@sraco1.us.sra.co.jp> nisinaka@sraco1.us.sra.co.jp ( Hello!!  This is JaMira speaking ) writes:
>In article <467@oha.UUCP> tony@oha.UUCP (Tony Olekshy) writes:
>   >>I just spent way too long debugging:
>   >>	     (mapcar '(lambda (son) (send son :rpt-output menu$width))
>   >>		 (reverse menu$sons))

>     I had a same problem, and

[fix involving protecting pointer fun in xlapply deleted]

>this works well so far.

>     I hope this works for your case, too.

Yes it will work, but it doesn't truly address the problem and wastes
a position in the stack. Normally fun would not need to be protected, since
its value is the same as that in the argument stack (which also gets
garbage collected). The problem comes when fun is a CONS (as in the
original posting), and gets reassigned. Sometime ago, a fix was posted
by Paul vanNiekerk that addresses the problem by storing the new function
back into the argument stack.

To fix, in xlapply() find the line "fun = xlclose(..." and replace
with "xlfp[1] = fun = xlclose(...".

Copies of xlisp distributed by me have this patch applied.

As to the original poster's comment about the functional arguments
	(lambda ...)
	'(lambda ...)
	#'(lambda ...)
seemingly performing the same way. The don't, and its not an error.
The documentation states that the function argument given to eval can be
a closure (first and third case) or a cons where the car is LAMBDA.
In the second case, the closure will be built within the mapcar (in this case)
function, and thus will have different free variable bindings than in the
first or third case. The first and third case are identical in operation.

Note that if a defined function was used instead of the lambda expression,
then only #'fun will work since the other forms will use the value binding
of fun.

--
Tom Almy
toma@sail.labs.tek.com <<< Note new address
Standard Disclaimers Apply