Number: 1507

Date: 26-Jun-84 13':48':47

Submitter: Sannella.PA

Source: HThompson.pa

Subject: ERRORTYPELST unusable': ERRORPOS not set correctly by ERRORX for errors in \-fns

Lisp Version: 

Description: '
Date': 24 Jun 84 14':01 PDT'
From': HThompson.pa'
Subject': Lisp': ERRORTYPELST/ERRORX bug'
To': LispSupport.pa'
Lisp-System-Date': 21-Jun-84'
Machine-Type': Dorado'
'
ERRORTYPELST entries can no longer be made to work completely satisfactorily, because for their purposes ERRORPOS is not being set correctly by ERRORX when the error comes from compiled code whose name starts with \.  Reason is that ERRORX uses REALSTKNTH, which does the right thing for BREAK, but the wrong thing for the RETAPPLY in the code which handles ERRORTYPELST, because it misses the offending frame.'
'
What a pain!'
'
Note also that the manual entry for ERRORTYPELST is wrong - only one FORM is evaluated, not a list thereof.'
'
Given that the only way to "solve" this is to completely reword the error system, at the very least a note should be put in the manual to the effect that the efficacy of ERRORTYPELST entries with respect to compiled code is limited at best.  For instance the example given in the manual will NOT work if the function causing the error is as follows, and compiled':'
(LAMBDA (X) (IPLUS X Y)) where Y is bound higher up to e.g. NIL.  Reason is that ERRORPOS will be at the function, not at \SLOWIPLUS2, so the SUBST in the ERRORPOSLST handling will happen at the wrong frame, and the result will be an infinite loop!'
'
Best of all would be to simply remove the facility altogether - let hackers advise ERRORX2 or something.'
'
ht'
'
-----'
'
Date': 26 JUN 84 18':03 PDT'
From': MASINTER.PA'
Subject': AR#1507, ERRORTYPELST'
To':   HThompson'
cc':   LispSupport, burton'
'
Until I''m convinced otherwise by inability to rectify, I believe this is a simple BUG in the error system which crept in at some point and which is fixable. '
'
Calling it otherwise (and calling upon a reworking of the whole error system) is perhaps drastic, although given your previous attempt to spec out a rework of the error system, understandable.'
'
If you were here, it might be different... '
'
Larry'
'
-----'
'
Date': 27 JUN 84 07':43 PDT'
From': HTHOMPSON.PA'
Subject': Re': AR#1507, ERRORTYPELST'
To':   MASINTER'
cc':   LispSupport, burton'
'
In response to your message sent  26 JUN 84 18':03 PDT'
'
The reason I called it irremediable is that as I read the error'
code, ERRORPOS is serving double duty, and cannot do both'
jobs correctly.  One job is to identify the frame to BREAK, should'
that be necessary.  The other is to identify the frame to correct if'
ERRORTYPELST calls for that.  The first job wants \ frames to be skipped'
over, teh latter does not.  The problem arises from the overloading of'
the concept of dummy stack frames and REALSTKNTH.'
'
In any case, the method ysed by ERRORTYPELST, to actually substitute blindly into the frame, is surely not allways the right thing to do.  Other, correct, arguments may be changed by the substitution unintentionally.'
'
Don''t know wht the rght thing to do is...'
'
ht'
'
-----'
'
Date': 27 Jun 84 13':11 PDT'
From': masinter.pa'
Subject': Re': AR#1507, ERRORTYPELST'
In-reply-to': HTHOMPSON.PA''s message of 27 JUN 84 07':43 PDT'
To': HTHOMPSON.PA'
cc': MASINTER.PA, LispSupport.PA, burton.PA'
'
Originally, the possible level of nesting of \ functions was quite small, and the possibility of an error below one was reasonable.'
'
How about if we make ERRORTYPELST mechanism a little more heuristic? I.e., try ERRORPOS and then if that doesn''t have the offender, try the last frame that DOES contain the offender?'
'
ERRORTYPELST is a hokey mechanism which is often *not* the right thing to do, but that doesn''t mean we should gut it, because it seems to work pretty good for another large class of applications.'


Workaround: 

Test Case: 

Edit-By: Sannella.PA

Edit-Date: 28-Jun-84  9':51':17

Attn: Masinter, burton

Assigned To: 

In/By: 

Disposition: 

System: Language Support

Subsystem: Stack and Interpreter

Machine: 

Disk: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Difficulty: Moderate

Frequency: Everytime

Impact: Serious

Priority: Hopefully

Status: Open

Problem Type: Bug

Source Files: