[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: LISP
- From: TEITELMAN
- Date: Fri, 15 Feb 1980 00:15:23 -8000
- Date: 15 FEB 1980 0015-PST
larry reported a serious problem in current loadup which is that any
iteraive statement containing a COLLECT which does not
translate into a mapcar, e.g. a collect with a WHILE or a BIND etc.
does not dwimify correctly.
(1) there is a new loadup which I believe fixes the problem. Hoever,
the fix was not straightforard and it is possible i may hve introduced
a new problem. if anything develops while i am away, you can simply
(2) repair the fix in the current byte.sav by remproving the
I.S.OPR property from fcollect (thereby causing it to translate
using the (SETQ $$VAL (NCONC1 $$VAL body)) translation.
the problem stemmed from fcollect, which is the nly i.s.opr in
the world which both evaluates its argument,
and also defines an i.s.type. the problem is that
it used to be handled by a kluge to take into account the fact that
there wasnt anyay to compute the i.s.type so as to use a dummy
variable, and also compute an expressionwhich bound the
same dummy variable. similar i.s.oprs for inside used
to do something like (SUBST (GENSYM) 'VAR exp) where
exp included the BIND. but in fcollects case, this didnt work
because the BIND and the i.s.type had to be handled separately.
I had fixed this up in general but not handled the fcollect case
In case any ofyou wish to use the new faciliy, which is somewhat cleaner,
thre is now a functon called GETDUMMYVAR
which is to be called from inside of an i.s.opr. It first
takes variables from the list ($$TEM1 ... $$TEM6) and then uses
GENSYM. If its argument is T, it ALSO effectively binds the
variable, i.e. puts it in the progvars list. To see how it is used,
look at the i.s.opr def for fcollect, and also for inside, outof etc.