[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Context of &OPTIONAL and &AUX calculations
- To: GJC at MIT-MC
- Subject: Context of &OPTIONAL and &AUX calculations
- From: Jon L White <JONL at MIT-MC>
- Date: Sat, 1 Aug 81 16:26:00 GMT
- Cc: BUG-LISP at MIT-MC
- Original-date: 1 August 1981 12:26-EDT
Date: 1 August 1981 12:14-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: I hate to tell you but...
(DEFUN G (Y) (SETQ X (+ X Y)))
(DEFUN H (&OPTIONAL (X (G X))) X)
I'll admit that the example is contrived, however, note well
that it used to work, when the code generated was a simple
use of LET* . . .
At one time, the LISPM did the following for &OPTIONAL and &AUX calculations:
1) Create a bind frame with all the relevant variables in it, being bound
to their previous values, if any.
2) Sequentially set each &OPTIONAL variable to either the input arg [which
might mean no code output], or set it to the default calculation.
Then sequentially set each &AUX variable to its calculation.
This order has the happy effect that &OPTIONAL and &AUX calculations don't
disturb any special variable bindings in the outer contour, where there
is an ** apparent LAMBDA binding ** of that special variable in the function.
I still feel that that original scenario is the better one, since it
is more in accord with the notion that the implicit LAMBDA binding of
the argument variables will "shield" the outer contour.
Could this situation possibly have any practical significance? or is
it only going to occur in, as you say, "contrived" circumstances?