Re: bug in {name}:operator ?

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

In article <27665@sophia.inria.fr>, Guido.Bosch@loria.fr (Guido Bosch) writes:
=> The function {name}:operator has a strange behavior if it is called
=> with a symbol that is not the name of an operator:
=> ? (setq formalism ({name}:formalism 'Glider))
=> Glider : tables read.
=> = #<formalism Glider>

=> ? ({name}:operator 'coco formalism)
=> ***** Fatal error : no room for lists.

=> What is the correct way to test whether an operator with a given name
=> exists or not in a formalism??

This is the correct way, and  if the named operator doesn't exist there is an
exit "not-found", as mentioned in the doc (core, virtual tree processor, pg 15).

In fact, all goes as documented when i try your experience here:

? (setq metal-formal ({name}:formalism 'METAL))
= #[METAL 0 ((((comment_s * ((COMMENT ((meta 0 metavariable) (#[METAL 0 (...
?
? ({name}:operator 'toto metal-formal))))
** toplevel : undefined escape : (not_found (1 operator_table toto ((((comment_
s * ((COMMENT ((meta 0 metavariable) (#[METAL 0 (
(((comment_s * ((COMMENT ((meta 0 metavariable) (#[METAL 0 (...
?
? ({name}:operator 'zone_s metal-formal))))
= ((zone_s + ((ZONE ((meta 0 metavariable) (#[METAL 0 ((((comment_s * ((COMMENT
 ((meta 0 metavariable) (#[METAL 0 ((((comment_s ...
?

What surprises me is the result of your "setq formalism" since your formalism
is displayed as #<formalism Glider>, i assume you've changed the printing of 
the vtp objects.  You haven't somehow changed the structure by redefining some
standard function?!

		--janet