Number: 1324

Date:  4-Jun-84 14':18':55

Submitter: JonL.pa

Source: JonL.pa

Subject: SELECTQ/SELECTC should use EQUAL semantics

Assigned To: 

Attn: Masinter, Kaplan,JonL

Status: Open

In/By: 

Problem Type: Design - UI

Impact: Annoying

Difficulty: Easy

Frequency: Everytime

Priority: Perhaps

System: Language Support

Subsystem: Other

Machine: 1132

Disk: 

Lisp Version: 31-May-84 22':31':16

Source Files: 

Microcode Version: 5124

Memory Size: 4096

File Server: 

Server Software Version: 

Disposition: '
["JonL.pa" "25-Sep-84 02':45':57" Attn': Description':]

Description: EQ is too sever a limitation on SELECTQ and SELECTC -- since the selectable items are available at compile time, then the compiler can decide whether to use EQ or EQUAL on an item-by-item basis.'
'
Date':  8 Jun 84 20':09 PDT'
From': JonL.pa'
Subject': Re': SELECTC'
In-reply-to': Masinter.PA''s message of 8 Jun 84 17':45':46 PDT (Friday)'
To': Masinter.PA'
'
Uh, the optimization is this':  For any "wing" of the SELECTQ/SELECTC for which the key is either a litatom, or non-zero smallp, then just do EQ; otherwise do EQUAL.  For "wings" with multiple keys, just repeat the advice, but have each "sub-wing" join back into the main "wing" upon success.'
'
Assuume that we have an opcode for EQUAL which will do the trivial cases quickly; i.e., it tries EQ first, and when that fails it sees if the typecodes are different and if so gives out NIL, and when that fails it sees if the common typecode is litatom or smallp and if so gives out NIL, and when that fails it calls the UFN.  Then the abovementioned optimization won''t be necessary.'
'
With either choice, (SELECTQ 0.0 (0 FOO) ...) will select FOO, albeit going through the EQUAL macrocode;  but still (SELECTQ 0 (0 FOO) ...) will win fastly.'
'
-- JonL --'
'
'
Date': 11 Jun 84 11':52 PDT'
From': JonL.pa'
Subject': Re': SELECTC'
In-reply-to': MASINTER.pa''s message of 8-Jun-84 23':21':09 PDT'
To': MASINTER.pa'
cc': JonL.pa'
'
I agree, this is a longer-term change, with serious compatibility consequences.  We should start by advertising an "intent to change" soon.'
'
By the bye, I foolishly reproduced what I thought was a typo in your message'
   (SELECTC 0.0 (0 FOO) ...)'
whereas I thought you were meaning'
   (SELECTC 0.0 (0.0 FOO) ...)'
Zero isn''t different here, the result would be the same with 3.0 and 3; but in neither case would EQ be satisfactory.'
'
-- JonL --'
'


Workaround: Use COND

Test Case: (SELECTC FROB (1 x) (MAX.FIXP y) ...)

Edit-By: JonL.pa

Edit-Date: 25-Sep-84 02':45':58