Re: CENTAUR (exit abstract_syntax

[jmi@columbo.inria.fr (Janet Bertot)]

In article <27820@sophia.inria.fr>, durrieu@tls-cs.cert.fr (Guy Durrieu) writes:
=> I got an error which is not very clear for me.

=> In a program transformation algorithm, I replace a subtree by another subtree,
=> which in this case simply was a *copy of the first subtree*, a singleton:
=> ((((colon 0 singleton) (#[transe 0  (... [ delete the rest of the tree ]

=> The exception raised is the following:
=> ** toplevel : undefined escape : (abstract_syntax (1 appartient ((((colon 0 
=> singleton) (#[transe 0 (... [ deleting the rest of the tree again ]
=> what happens?

Okay, since you didn't say exactly how you created or changed your tree, 
i'll just give some ideas of what can be going on.  There are two possible
calls that you could have made for changing the subtree:
	1) {tree}:replace <old-tree> <new-tree>
	   This function documented in the Core's virtual tree processor
	   manual, raises the exception abstract syntax.

	2) {variable}:change <var> <old-tree> <new-tree>
	   This function described in the Core's path manual has the 
	   advantage of being a higher level function working on a variable
	   and storing modifications for its associated tools.  The advantage
	   of using this function is that if your tree is on the screen, in a
	   ctedit, then a call to variable change will trigger the necessary
	   update of the display.  NB: this calls {tree}:replace along the way.

Now one would assume that calling either of these functions with new-tree 
equal to a copy of old tree should work without error.  For example,
	({tree}:replace <old-tree> ({tree}:copy <old-tree>))

However, this depends on how you constructed your tree.  Was the original tree
parsed (using a parser constructed using either Metal or SDF)??  Or did you build
your tree by hand calling the {tree}:make primitive.  If it were the latter, you
should check the original tree construction.  The virtual tree processor manual
contains the following warning:

	{tree}:make <operator> [ <tree1> ... <treeN> ] -> <tree>
Returns an object of class tree labeled with <operator> and with <tree1>, ...,
<treeN> as sons.  WARNING: no verification is done either on the number of
actual arguments or on abstract syntax constraints.

Thus, it is possible that the constructed tree has a son, who violates the 
abstract syntax constraints, and it is only on the {tree}:replace that the error
is raised.

=> Another question: is it possible to implement some kind of "unwinding" menu,
=> that is, a menu the buttons of which open other menus..? I have many things to
=> put in my menus.

By "unwinding" menu, i assume that you mean a "walking" or "cascading" menu 
that was/is popular in various systems.  Unfortunately, these are not provided
for by the gfxobj widget set.  In fact, what we see our users doing and what we
ourselves prefer to do is to use a ctedit as a menu.  That is, you use the
contents of a ctedit, centaur structure editor, as a menu.  This has a number of
advantages.   Of course, visually this is satisfying as one gets the scrollbars
and colors for highlighting information.  Not to mention that one can have menus
for "different levels" of users (such as beginner's and experts) giving more 
or less details.  Also the selection of "items" of the menu (i.e., clicking on 
some subexpression in the ctedit) can provoke different actions based on the 
different mouse buttons used, etc.  

This is done for example, in the "Guided Editing" tools that are provided in 
the Centaur 1.2 distribution in the "contrib/menumode" directory.  Here several 
menus are provided that allow, for example, template edition and program
transformations.   The choices available in the menu can be changed dynamically
to correspond to the current selection in the source program as well.
That is, at any time a menu can contain only those transformations that are 
applicable.  There is a 15 page document describing the menu-mode mechanism
on the centaur1.2 tape (Cf. <root-directory>/docs/menumode/main.ps).  Is your
menu long because you don't selectively show those choices that apply given
the current selection in ctedit?!  Would you be interested in this sort of 
ctedit menu??

	--janet