|Syntax directed program editing firstname.lastname@example.org (1992-02-05)|
|Re: Syntax directed program editing email@example.com (1992-02-06)|
|Re: Syntax directed program editing firstname.lastname@example.org (1992-02-15)|
|Re: Syntax directed program editing nickh@CS.CMU.EDU (1992-02-07)|
|Re: Syntax directed program editing email@example.com (1992-02-07)|
|Re: Syntax directed program editing firstname.lastname@example.org (1992-02-07)|
|Re: Syntax directed program editing email@example.com (1992-02-11)|
|From:||firstname.lastname@example.org (Dr A. N. Walker)|
|Organization:||Maths Dept., Nott'm Univ., UK.|
|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
while condition do
begin statement3; statement4 end;
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.
[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]
Return to the
Search the comp.compilers archives again.