Dear Chris, thanks for your analysis and your suggestions. Currently I am wondering if it would be a good idea to open a special CVS branch for the function class modifications. With that the release of a GiNaC 1.4 would not be delayed or poisoned by these big modifications and the development of the function classes would proceed more publicly. Chris Dams schrieb:
GINAC_IMPLEMENT_FUNCTION_OPT(exp_function, print_func<print_csrc_float>(&exp_function::do_print_csrc_float). print_func<print_latex>(&exp_function::do_print_latex))
This looks a bit too much like the old system IMO. Isn't it possible to have virtual functions do_print_csrc_float and do_print_latex? The default behaviour of these would then be to print the name of the function (prefixed with a backslash in case of do_print_latex) and the argument list. Since I found a method virtual const char* class_name() in function.h this shouldn't be a problem.
Some kind of macro for the initialization of the static members has to be used in any case. So I guess you are more concerned about the _OPT part of it, i.e. the print_func stuff. If one wants to keep the double dispatch mechanism alive for function classes, there is not much else one can do but to use a macro such as the one displayed above. Simple overloading won't do. Of course, the function class itself could sport good defaults for all functions and thereby making the use of the considered macro unnecessary in most cases. This is what you are proposing, but what I found difficult to do. For print_latex I can imagine two alternatives: \functionname or \mbox{functionname}. Most built-in functions use the former, but most user defined ones probably want to use the latter ... Maybe the following would do: have a (not complete) list of latex-built-in functions and the default latex printing functions chooses the \func variant in case the name is in the list, otherwise it chooses the \mbox variant. Too bloated? I have (not yet ripe) ideas for print_csrc that are beyond the current printing mechanism, i.e. one also wants to evaluate function like tgamma or zeta in C programs of course ... Apart from that, a default that removes the _function suffix should do (expect for abs).
(1) It should be possible to declare a function without the _function suffix. The three reasons that you mention for the need of the suffix do not apply seem to apply to most user-defined functions, so I think it is
yes, but ...
good if users can avoid having to suffix every function they define. This would avoid having to have code like
ex thing(const ex& x1) { return thing_function(x1); }
maybe there are also advantages of a consistent naming scheme. At first I had only built-in functions with the _function, or _ginac as richy suggested, extension that collided with cmath functions and all other functions went without it. Then I thought about defaults for printing and because I didn't want to have the _function part of the name automatically removed for user defined functions (maybe he *really* wants a function to be named BLA_function and also printed like that ...) I had to write printing functions for almost _every_ built-in function. It looked kind of short-witted. Then I thought about the inconsistency for the user: if he uses for example is_exactly_a<> for built-in functions he has to append _function to the name otherwise not. Maybe the user chooses a name for his function that is already in cmath (or any similar dominating header ...), then he might get some subtle errors in his programs like the ones that are avoided by the special naming for built-in functions. So in the end I chose to treat every function the same. But I am still not satisfied with this and I like what you are proposing! So I will re-think this decision. Maybe some other trick will do (namespaces?).
(2) I would like to see a possibility to inherit from another function. Maybe by doing something like
class my_sine : public sin_function { GINAC_DECLARE_INHERITED_FUNCTION(my_sine, sin_function); ... etcetera ... }
Should be possible. Just needs more macros. Will be done. Regards, Jens