AW: [GiNaC-devel] AsyForGiNaC - an output extension producingAsymptote files

[Jens Vollinga]

Dear Daniel,

Daniel Seidel schrieb:
>> [Jens from like two mails ago] ...The only thing needed therefore is - at
>> least to me, correct me if I am wrong - a new printing context.
> [DS]Including the functions like 'class print_asy : public print_dflt' is
> not a good idea, because the fallback goes first down the print_context and
> so instead of using the basic print_asy it will use a print_dflt output if
> defined. Bad.

currently I am thinking this is good. Maybe I can convince you as well. 
Let's look at latex format. There you have

class print_latex : public print_context

In case a class doesn't handle print_latex (some developer was lazy, for 
example) it defaults to "normal" printing. It doesn't raise an 
exception. In lots of cases the "normal" output is no valid latex 
syntax, so the latex interpreter will complain. But still you have the 
full output. You could load the output in some text editor and fix the 
output quite easily.

If after some long calculation somebody's program starts to print its 
(often comparatively small) result and just "crashes" with an exception, 
lots of somebodies would probably be very annoyed. They could file a bug 
report and wait until somebody fixes the source code (the advanced user 
may correct the bug(?) for himself, of course). But the aforementioned 
option to correct the buggy output in some text editor is not possible. 
Essentially they would have to (wait for help and then to) run their 
program again.

The same is probably true for asymptote output. There you would just get 
let's say a "sin(x)" for example instead of some more elaborate 
asymptote code. Either Asymptote will complain or produce bad graphics 
then. But it is very likely that one is able to fix that afterwards with 
some search and replace (and then file a bug report, of course).

> [DS] Before producing new code we should agree about the design. I hope we
> agree about the disadvantage of the print_context fallback. The basic thing

Let's say you do something like

class print_asy : public print_context
class print_asy_differently : public print_asy
class print_asy_even_more_advanced : public print_asy

then you could define functions like

mul_print_asy()
add_print_asy_differently()
...

at first separately from GiNaC sources (later these functions could be 
made member functions, NON-VIRTUAL member functions, cf. 
basic::do_print_tree()),

and then gather commands like

[weird stuff].print_func<print_asy>(&mul_print_asy)
...

in some central source file.

By 'at first' I mean 'until the change rate allows for a decent CVS 
commit schedule'.

> that should be possible is to write classes derived from GiNaC::basic and
> adjust printing options, still keeping the unified interface. If you have a
> better idea than adding the print methods to GiNaC::basic virtually, I would
> agree luckily. But I don't know how to do it else.

The code example gives an idea how it can be done.

Regards,
Jens