Interlisp
FASLOAD doesn't respect LDFLG
This became apparent in a recent meeting: (LOAD 'XXX.DFASL) and (LOAD 'XXX.DFASL 'PROP) are equivalent: they both store the new compiled definition in the function cell.
FASL:PROCESS-STREAM doesn't take LDFLG as an argument. Indeed, there is a comment in the code that says that it binds flags internally so that DFASL files are essentially loaded SYSLOAD.
Seems like a bug.
For one thing, it means that GITFNS can't use CALLSCODE to compare the signature of compiled functions, as @masinter suggested. The comparison would smash the current environment.
looking at the code for this, there are a couple of issues that I think need resolving:
- Global vs special variables: I'm not sure this is in the IRM anywhere? Medley has several kinds of binding: global binding, special binding, lexical/local binding, with corresponding access methods: global variables (accessed by a simple GETBASEPTR from the value ccell of the symbol), free variables (accessed by a cached lookup searhing up the stack for a frame that has a special binding -- lookup location is cached), and lexical access (get out of the stack if not in a closure; variables acceed via a closer are looked up in the 'closure' object for this context).
The compiler should be called consistently to compile variable binding and variable access. This is a problem for global / special variables, because binding and access are compiled independetly and the declarations might not be the same.
Interlisp has a means of establishing a dynamic context for access of global variables, called RESETLST / RESETSAVE. If you want to temporarily set a global when you start and reset it back when done as a kind of "dynamic binding", this sets the global variable's access sate.
This is a problem with processes -- it's one of the main reasons why RESETLST isn't "thread safe".
