GiNaC/ginac print.h ...

[Pearu Peterson]

Hoi GiNaC people,

On Fri, 6 Apr 2001, Christian Bauer wrote:

> Log Message:
> - replaced the various print*() member functions by a single print() that
>   takes a print_context object that determines the output formatting; this
>   should make it easier to add more output types

In Python standard there are two output types: 
one for pretty print (str), e.g.

   str(add(power(2,symbol('n')),3))  -> "2**n+3"

and another for reproducible print (repr), e.g.

   repr(add(power(2,symbol('n')),3))  ->
                       "add(power(numeric('2'),symbol('n')),numeric('3'))"

In order to use GiNaC from Python, I used print() function for str() and
printraw() function for repr(). For that I re-implemented
GiNaC::*::print*() functions, and when linking, I used their compiled
codes before -lginac. This hacky method worked perfectly and it was the
only way to introduce a new output type (for Python) without modifying
GiNaC sources.

Now, with this new print() standard, nothing has changed. I still have to
re-implement print() function in the same way again:(. But looking
forward to future where you might support output types such as LaTeX,
MathML, etc. that could be useful also from Python, my approach doesn't
feel right. And on the other hand, you hardly want to support Python
(or any other third party language) output formats.

So, I am wondering if it would be possible for GiNaC to support *external*
output types? For example, by a special print_context object, say,
print_callback, that contains an user-defined function for printing ex
object and it is called from print() function with an additional argument
(TINFO_*) saying who called it (e.g. symbol::print or matrix::print).
In this way all printing stuff could be collected in a separate file and
it should be possible to define optional output formats without modifying
GiNaC sources.
What do you think?

Regards,
	Pearu