#R10/11 lisp difference
4 messages in this thread
Tony, I replied to this message but it must have slipped through the cracks
<g>. The problem was not with a mapcar-lambda difference between 10c7 and
11c2 as I originally thought. I originally stated that it was 10c2 but I
forgot? that we are using 10c7 now. The lists that were fed to
mapcar-lambda were different as you suspected. The difference was found in
the part of the routine that generated the lists. In 10c7 the expression
(< nil 0) returns nil while in 11c2
(< nil 0) returns T
This is easy enough to program around one you know about it. Has this
difference been documented and are there any others like it? I have
reproduced the above responses on various copies of 10c2 on various
machines but have only one copy of 11c2 to try. Thanks
Larry Leuallen
Larry comparing Nil to the integer ZERO is not a valid operation to begin
with. Why are you doing this?
The expression (< nil 0) should cause an error, since the values can't be
compared, but in any case, you should never do this, because the result is
always meaningless. Perhaps if you explain what it is you are trying to
test with that expression, I could suggest an alternative.
-TonyT.
Tony, I agree that (< nil 0) is meaningless. I did a conditional that
worked in 10c7 and did not work in 11c2 and found that the reason was the
different values (T vs nil) returned. It struck me odd that the different
releases should be different.
Of course is did not feed nil into the expression directly. The actual
expression was something like (< (cdr (assoc 62 tbl-x)) 0) where tbl-x is
the association list for a layer obtained by stepping through the layer
table. The last loop through of course returns nil resulting in (< nil 0).
In 10c2, this returns nil so the expressions of the condition are not
evaluated as desired. This blew up in 11c2 due to returning T which
evaluates the expessions.
Once I determined the cause the fix was easy. If I had been smart I would
of used minusp to test the condition which would have failed in either
case. In fact I did, and worked around it by using the above (wrong!) which
worked in 10 and bit me in 11 when I tried it. If I had found the real
cause of why minusp did not work and fixed it would have not been a
problem.
If I had been real smart I would have used the bitwise operators but you
have not written that paper yet <g> so I haven't gotten that far.
I guess I was suprised by the lack of consistency.
Thanks for your ear. Larry Leuallen
Larry – No, you don't need bitwise operators or (minusp) to find out when
you've hit the end of the layer table. You should always check to see if
you've reached the end of the table, by using (while). For example:
(setq tbl-x nil)
(while (setq tbl-x (tblnext "layer" (not tbl-x)))
<process each layer's table entry here>
)
The above loop will stop when it hits the end of the table, without executing
the expressions in the body of the loop an extra time.
-TonyT.