Number: 1318

Date:  1-Jun-84 16':18':50

Submitter: Sannella.PA

Source: JonL.pa

Subject: Error in FUNARG pointing to top environment  ->  catatonia

Lisp Version: 

Description: '
[lmm 7 Jun 84': note that my implementaiton of process globals would get rid of this problem, because MAKEPROCESS would no longer have to bind any of the variables]'
'
Date': 25 May 84 18':18 PDT'
From': JonL.pa'
Subject': FUNARG lossages, and PROC-created toplevels.'
To': Cooper.pa, Wallace.pa, DesRivieres.pa'
cc': JonL.pa, vanMelle, LispSupport, Bobrow, Newman.es'
'
...'
'
On the other hand, I''ve come across a more serious lacunae.  Suppose you have tow variables, say NotBoundAtTop which is unbound in the top environment, and FOO which has some random topval.  Then at LISPX level type'
    (SETQ G4 (FUNCTION (LAMBDA () NotBoundAtTop) (FOO)))'
The resulting funarg will be rooted "at the top"; trying to Apply it will cause an unbound variable error, and the world''s error machinery dies a horrible death of catatonia (not responsive to ^D nor ^C nor mousing nor anything else except CTRL-SHIF-DEL).  It seems that the multi-process world expects a PROC-created frame at the top of the world that holds some crucial system bindings as SPECVARS.  Like \TERM.OFD maybe.'
'
What''s the solution? should the rooting be to the top of the current process rather than the global environment, or should the global environment have enough of a stub to be workable despite the intervening PROC frame?'
'


Workaround: 

Test Case: 

Edit-By: Masinter.PA

Edit-Date:  7-Jun-84 14':42':10

Attn: masin, jonl, vanM

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: Moderate

Priority: Perhaps

Status: Open

Problem Type: Bug

Source Files: