xerox 19771027_Debugger_Interpreter_Part_2 free download

File name 19771027_Debugger_Interpreter_Part_2.pdf

Inter-Office Memorandum To Mesa Group Date October 27, 1977 From Barbara Koalkin Location Palo Alto Subject Debugger Interpreter - Part 2 Organization SOD/SO XEROX XEROX SDD ARCHIVES I have read and undelstuod Pages ___________To __________ Filed on: [MAXC]DWG1.bravo Reviewer Date DRAFT ---- '# of Pages _ _ Ref'.,1V12J)-359 This memo represents a summary of today's discussion on the proposal for the debugger interpreter as well as other topics of interest regarding the Mesa 4.0 debugger. The basic thought seems to make the interpreter simple but complete. The grammar for the interpreter may be found on the attached pages. It was decided to make the syntax itself very general in order to allow room for expanding, however we intend to limit what will be included in the first implementaion. It was decided to "buy" the front end of the compiler and modify it to fit the grammar of the interpreter. We will need to modify the scanner, modify the parser to accept the reduction rules of the debugger, and generate a module to do the actual interpreting. The question of context brought up some interesting discussion. It was decided that values will be interpreted in terms of the current context (by default). However, you may specify a particular module or definitions file by typing name$foo (more on this syntax later). On the issue of what kind of user interface the interpreter should have, it was decided to keep the present set of INTERPRET commands and have the new interpreter run off a separate command (SP was proposed) until its reliability is well proven. It was decided to do a two pass interpreter; parse once looking for valid syntax, if everthing looks ok then do the second parse for evaluating on the fly. This method was chosen so as to avoid the canonical case of having imbedded procedures ca1\s causing core swaps (with high time costs) before finding a simple syntax error. The QualifiedAccess question reduced to the following two cases: ie., you want to have p.q (1) if P is a pointer to a record, use the "." (2) if p is a module name or definitions file, use the "$" The following lookup algorithm was decided on: $ means look through the current context and its imported contexts, followed by the module table of the BCD and then look for a file. If the time cost proves to be too high using this algorithm we will consider introducing a new notation to distinguish between the case of naming a defs file from