Text preview for : 19771027_Debugger_Interpreter_Part_2.pdf part of xerox 19771027_Debugger_Interpreter_Part_2 xerox sdd memos_1977 19771027_Debugger_Interpreter_Part_2.pdf
Back to : 19771027_Debugger_Interpr | Home
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 an included context vs. naming a random file on the disk.
Debugger Interpreter - I>art 2 2
To accomplish our goals some new notation was proposed:
Interval will be a new type of qualification. The initial implementation will be only for
printing purposes and therefore an Interval will not be allowed on a left side or embedded
inside other expresssions. The syntax looks as follows:
LeftSide := ... I ( Expression) Qualifier I LeftSide Qualifier I MEMORY [ Interval]
Qualifier :=