Dear Jens, On Tue, 18 Apr 2006, Jens Vollinga wrote:
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.
Yes, I think that is a good idea. Do you plan to release 1.4 soon? I still have some changes in my local CVS-tree that I would like to see going into it, but that I would like to test a bit more before comitting them. Unfortunately, it involves adding two new functions and two new function options, all coded within the old system, of course... :-(. And you will also have to document your new tinfo-system. The tutorial still uses the old one.
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 ...
Yes, I think the function class should provide good defaults.
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?
There could be an implementation using GINAC_IMPLEMENT_FUNCTION_OPT for built-in functions and the default \mbox{functionname} for user-defined ones. On the other hand, considering the fact that after it a "(" will come, I think \mbox{functionname} is not too bad as an implementation even for, say, the sine.
(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?).
Hmmm... It sounds like every solution has disadvantages. Yet another ugly idea: a function that is declared as thing_function, has GINAC_DECLARE_FUNCTION also emit the code friend ex thing(const ex&x){return thing_function(x);}. Note the use of "friend" to be able to declare an ordinary function inside a class body. Best, Chris