Re: Centaur's data base.

[Vincent.Prunet@sophia.inria.fr (Vincent Prunet)]

=>    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?

Not yet.

When a tree is pretty printed, several attributes may be used to specify the
color and font of displayed material. We currently use the class (a ppml
specific attribute dynamically computed from the pretty print specification),
the pretty printer style (always line), the pretty printer name, and a
resource named formalism which default value is the formalism name of the root
of the tree (but a different value may be set).

If a subtree belongs to a different formalism, a different pretty printer may
be run to unparse the subtree. But resource values for color and font
attributes are computed according to the calling context (that is the already
computed resource prefix), and do not take into account the current formalism
and pretty printer.

I agree with Jean-Michel Hufflen that this is an error and should be fixed.

One could simply switch to a new prefix computed from the new formalism and
inner pretty printer name. But this solution is not satisfactory, the outer
pretty printer and formalism are forgotten (except by the choice of the inner
pretty printer).

A typical example is:
let use the std inner pretty printer, but with special colors (which fit
with the outer pretty printer resource colors).
It should be possible to specify different resources values for the same inner
pretty printer, depending on the outer pretty printer and prefix.

A rather complex solution consists in extending the resource prefix to
include the name of the outer pretty printer and formalism.

I propose here another solution, where all the outer constraints are
summarized in a single name, called a palette.

First, the resource tree for graphic resources must be merged with the tree
for formalism, parsers and pretty printer location resources.


	Centaur.Formalism.PprinterManager.Pprinter.Palette
becomes the prefix of pretty print resources previously called displist
resources in the reference manual. As one can see, they no longer depend on
the ctedit name or visual-type.

The values of the outer pretty printer and palette for a given formalism in a
given ctedit are retrieved from tree formatter resources.

...Formatter.Formalism.Pprinter
...Formatter.Formalism.Palette

When a subtree belongs to a different formalism, resources specify the inner
pretty printer and palette corresponding to the inner formalism:

Centaur.Formalism.PprinterManager.Pprinter.Palette.InnerFormalism.PPrinter
Centaur.Formalism.PprinterManager.Pprinter.Palette.InnerFormalism.Context

The resource prefix is then changed according to the new formalism, pprinter
and palette. Nothing else is remembered from the outer environment
(outer formalism, pprinter or palette) until the subtree is unparsed.

The values of the outer pretty printer and palette for a given formalism in a
given ctedit are retrieved from tree formatter resources.

...Formatter.Formalism.Pprinter
...Formatter.Formalism.Palette


As the Centaur user may define an unbounded set of palettes, it is still
possible to get different resources on a ctedit name basis.


I'd appreciate a lot if Centaur resource users could take some time to analyse
my proposition and tell whether it would be satisfactory in their specific
environment. Any other proposition is welcome.

Vincent Prunet