Re: Syntax directed program editing

anw@maths.nott.ac.uk (Dr A. N. Walker)
Tue, 11 Feb 1992 17:17:51 GMT

          From comp.compilers

Related articles
Syntax directed program editing richard@harlqn.co.uk (1992-02-05)
Re: Syntax directed program editing pardo@cs.washington.edu (1992-02-06)
Re: Syntax directed program editing carroll@cis.udel.edu (1992-02-15)
Re: Syntax directed program editing nickh@CS.CMU.EDU (1992-02-07)
Re: Syntax directed program editing cherrman@borland.com (1992-02-07)
Re: Syntax directed program editing anw@maths.nott.ac.uk (1992-02-07)
Re: Syntax directed program editing anw@maths.nott.ac.uk (1992-02-11)
| List of all articles for this month |

Newsgroups: comp.editors,comp.lang.misc,comp.compilers
From: anw@maths.nott.ac.uk (Dr A. N. Walker)
Followup-To: comp.editors
Keywords: performance, design
Organization: Maths Dept., Nott'm Univ., UK.
References: 92-02-024 92-02-037
Date: Tue, 11 Feb 1992 17:17:51 GMT

In article 92-02-037 the moderator asks:


>[How do you handle changes like moving a statement across an "end" ? -John]


First of all, note that in a syntax-directed editor, there need be
no "end". Delimiters such as "begin", "end", "while" and "(" are
syntactic sugar that are displayed when showing the program to the user.
Eg., a sensible SDE grammar for a Pascal "while" statement would be


while_statement: condition compound_statement


rather than the conventional


while_statement: 'while' condition 'do' statement.


The display module will surround the "compound_statement" by "begin ...
end" if [and only if] it includes more than one "statement". The editor
won't let the user select the "end" [which may be visible on the screen],
because there is nothing the user can sensibly do with it.


So, if you have some Pascal like


statement1;
statement2;
while condition do
begin statement3; statement4 end;
statement5;


and you want to take "statement4" out of the loop, then from the user's
point of view, this is something like: select "statement4", position
cursor after the "while_statement", and use the "move" command. At this
moment, the "begin" and "end" would disappear and "statement4" would move
to just above "statement5". You could move it back by positioning the
cursor after "statement3" [in pre-mouse days this was cursor-up to get to
"while_statement", cursor-right to break into the statement, and two
cursor-downs to get past the "condition" and "statement3"] and "moving"
again, at which point the "begin ... end" would auto-magically reappear.


Behind the scenes, this is also quite easy: the "while_statement"
points to a linked list containing "condition -> statement3 -> statement4"
from which the last item has to be unlinked, and re-linked between
"while_statement -> statement5". You then call your display routine, and
rely on the optimisations of your termcap library to minimise the work
done. If you are incrementally compiling as well, then in the present
case there is no more to be done, but more generally you might need to
re-compile "statement4" in its new environment.


Or have I missed your point?


--
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk
[This seems to me to require a lot more mental effort by the user than a
text move of the "end", and having the begin and ends appear and disappear
automagically seems kind of baffling. But I am the first to admit that
opinions about editors are more than anything else a matter of taste. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.