Number: 1070

Date: 10-May-84 11':40':26

Submitter: Roach.pa

Source: Roach.pa

Subject: (SUBSTRING "FOO" 3 2) ought to give ""

Assigned To: 

Attn: Kaplan

Status: Declined

In/By: 

Problem Type: Design - UI

Impact: Moderate

Difficulty: Moderate

Frequency: Everytime

Priority: Perhaps

System: Language Support

Subsystem: Storage Formats/Mgt

Machine: 

Disk: 

Lisp Version: 

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["Kaplan" "15-Sep-84 03':09':17" Status':(Open->Declined) Description':]'
["Kaplan" "15-Sep-84 13':19':44" Description':]'
["Kaplan" "18-Sep-84 17':18':44" Description':]

Description: '
I don''t think SUBSTRING should ever give NIL.  It either should error or give a string back.  More important to me however is that SUBSTRING gives back NIL in cases where it ought to be giving back "".  For I from 1 to (ADD1 (NCHARS STRING)),'
we should have'
     (SUBSTRING STRING I (SUB1 I)) = ""'
The existing behaviour causes what could be an invariant'
     (EQUAL (SUBSTRING STRING 1 (NCHARS STRING)) STRING)'
to fail.  A form that could be written as'
     (RPLSTRING S1 (SUBSTRING S2 1 (IMIN 8 (NCHARS S2))))'
must be written more complicatedly as'
     (RPLSTRING S1 (OR (SUBSTRING ...) ""))'
Viewing STRINGPs as abstract data structures with LENGTHs & BASEs pointing into a string space, I do not think it is too hard to justify (SUBSTRING STRING I J) always returning a string whenever we have'
     N = (NCHARS STRING)'
     L = J-I+1 = (LENGTH (SUBSTRING STRING I J))'
     1 <= I <= N+1'
     0 <= L <= N-I+1     (same as I-1 <= J <= N)'
Maybe LISPCORE↑ will own up & fix this kruftiness? '
'
'
----'
'
I think Kelly is exactly right on this.  I''ve felt the same way for years.  But':  I think that too much of system and user code, in which the SUBSTRING might be used as a predicate, will stop working.  The only thing to do is to invent a new name with the proper semantics.  Until the name is suggested, this is declined.'
'
--Ron'
'
Date': 15 Sep 84 12':49 PDT'
From': JonL.pa'
Subject': Re': AR 1070':  SUBSTRING returning NIL declined'
In-reply-to': Kaplan.pa''s message of 15 Sep 84 03':09 PDT'
To': Kaplan.pa'
cc': Roach.pa, LIspsupport.pa'
'
For the record':'
'
CommonLisp does all substring/subatom/submumble type operations under the one name SUBSEQ, which is defined to return always a "sequence" of the same type as the input.  NIL could satisfy that requirement only for SUBSEQ calls on liststructure.  Incidentally, the null atom -- the one with 0 characters in it''s pname -- does exist in that world (HA! i just discovered that the null litatom exists in Interlisp too!) so a SUBSEQ call on a symbol (litatom) has an option other than the nullist when the "sequence" is null.'
'
-- JonL --'
'
Date': 15 Sep 84 14':17 PDT'
From': Roach.pa'
Subject': Re': AR 1070':  SUBSTRING returning NIL declined'
In-reply-to': Kaplan.pa''s message of 15 Sep 84 03':09 PDT'
To': Kaplan.pa'
cc': Roach.pa, LIspsupport.pa'
'
     SUBSTR could be a name, but I''ve already run at least one day where I redefined SUBSTRING to do the right thing and had no problems.  Maybe you could take the CAR/CDRERR flag approach to SUBSTRING.  First sneak a flag into SUBSTRING''s code that LISPCORE↑ members can set to T to get the proposed improved behaviour.  After a while, the dependencies on NIL being returned are removed from the system and the existence of SUBSTRINGFLG becomes known to ever wider circles of users.  Finally, SUBSTRINGFLG is defaulted to T, and assuming we''ve told users what we''ve been planning all along, we ultimately commit SUBSTRING to the correct behaviour, eliminating the now undesirable SUBSTRINGFLG.'
'


Workaround: 

Test Case: 

Edit-By: Kaplan

Edit-Date: 18-Sep-84 17':18':45