Number: 317

Date: 27-Mar-84 10':41':34

Submitter: Sannella.PA


Subject: (ZEROP 0.0) = NIL. Change ZEROP semantics.  

Assigned To: 

Attn: JonL

Status: Wish


Problem Type: Design - UI

Impact: Annoying


Frequency: Everytime

Priority: Unlikely

System: Language Support

Subsystem: Arithmetic



Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["" "23-Sep-84 21':00':09" Attn': Description':]

Description: '
[issue is confusion arising from (ZEROP 0.0) returning NIL. Resolution': warn users strongly in manual, (ZEROP 0.0) = NIL, and that they should probably use (EQP x 0) if they care.]'
Subject': ZEROP'
Don''t you people think its time to change the abomination called ZEROP?  If for no other reason than internal consistency of Interlisp, I suggest that you redefine ZEROP to be (EQP x 0) and define a new function IZEROP to be what the old ZEROP did.  While this is a change to an existing function (and therefore not to be done lightly) I believe more people have been bitten by this function than have counted on its strange behavior.'
Date':  2 APR 84 14':55 PST'
From': JONL.PA'
Subject': AR 317': ZEROP should be redefined'
Using the masterscope database for the system code (as well as many library packages) I could easily "fix up" any system usages for which this change would cause problems.  Also, I believe an OPENLAMBDA macro  definition for the new ZEROP, which would do a SELECTC on (NTYPX X) first (begfore doing a function call) would forstall any time-performance problems.'
From': Masinter'
Need to worry about NEGATE, and CLISPIFY and DWIMIFY.'
(lmm': I think these have now been taken care of.)'
From': JonL'
Date': 23-Sep-84'
I''ve ben converting instances of ZEROP found in critical, or semi-critical, pieces of system code into usages of (EQ 0 ...), so that as-and-when this change goes through, these places won''t be affected by the extra bytecodes needed to effect genericity.'


Test Case: 


Edit-Date: 23-Sep-84 21':00':10