Centaur's data base.

[Jean-Michel.Hufflen@loria.fr (Jean-Michel Hufflen)]

   I have encountered a modularity problem with Centaur's data base.  I am
explaining it in a simplified form.

   Let "L1" be a formalism name.  Its standard "PPML" can use some classes,
that is, the file "std.rdb" can contain some lines. such as:

	*visual-color*formalism-L1.pprinter-std*class-class1.Foreground: brown
	*formalism-L1.pprinter-std*class-class1.font: \
	-b&h-*-bold-r-*-*-12-*-*-*-*-79-*-*

   My files seem to me right: whenever I order to display an "L1" abstract
syntax tree within the formalism "L1", "PPML" recognizes the classes of "L1"
and works fine.

   BUT:

   let "L2" be another formalism name, whose specification includes this
abstract syntax operator:

	from_another_language  -> implemented as TREE ;

   and here are some excerpts of the standard "PPML" for "L2":

	prettyprinter std of L2 is
	  default
	    ...
	    pprinter = std ;
	  rules
	    ...
	    from_another_language *another_tree -> [<h> *another_tree] ;
	end prettyprinter

   Within the formalism "L2", if the operator "from_another_language" labels an
"L1" abstract syntax tree, the behaviour is the following:
   ---the *formatting* rules of the "L1" pretty printer are known actually and
put into action,
   ---but the *data* *base* (that is, the orders of
".../L2/pprinters/std/std.rdb") is ignored.

   As far I know, there are two solutions:

   ---to insert the same orders for the file "std.rdb" for "L2":

	*visual-color*formalism-L2.pprinter-std*class-class1.Foreground: brown
	*formalism-L2.pprinter-std*class-class1.font: \
	-b&h-*-bold-r-*-*-12-*-*-*-*-79-*-*

   but this solution violates modularity: each change of the classes of "L1"
has to be reported in this file for "L2";

   ---to change the previous orders in the file "std.rdb" for "L1" as follows:

	*visual-color*Formalism.pprinter-std*class-class1.Foreground: brown
	*Formalism.pprinter-std*class-class1.font: \
	-b&h-*-bold-r-*-*-12-*-*-*-*-79-*-*

   but this solution also violates modularity, since the name "class1" is no
longer local to the formalism "L1".

   Is there a better solution? That is, a way to use the database of the pretty
printer of "L1" whenever the pretty printer of "L2" has to display an "L1"
abstract syntax tree?

   Yours faithfully,

				 J.-M. Hufflen