[GiNaC-devel] New return_type_tinfo-system seems broken.

[Jens Vollinga]

Hi,

Chris Dams schrieb:
> label? The fact that in ncmul::eval it is necessary to check for
> Dirac/color objects indicates bad design.

I agree on that. And the new return_type_tinfo system is really just a 
quick and dirty fix that should be replaced by something better.

The problem with the adaptation of the original return_type_tinfo to the 
new tinfo system was, that not only did return_type_tinfo return a 
mixture of type information and representation label (bit patterns ...), 
but also it also returned this information from the first operand of 
objects like mul/add/...

So the workaround was to let return_type_tinfo return a reference to 
either its object or the first operand object in the case of add/mul/...

> Although the tinfo()-system has, arguably, been improved the
> return_type_tinfo-system has been demolished. What about the following
> replacement? Make return_type_tinfo return something of type tinfo_t. In
> that case the user can generate his own objects tinfo_t as he pleases
> and e.g. dirac_gamma could take an argument of type tinfo_t instead of a
> representation label.

I do not fully understand your idea, yet.
Instead of choosing a representation label the user chooses the tinfo 
for the the dirac_gamma object? But tinfo is static, isn't it!? What if 
he chooses something equal to another tinfo (unlikely but possible)?

> Does anyone feel like implementing this or shall I do it?

Currently I try to demolish the function system :-), so if you would 
volunteer to solve this problem, please do!

Regards,
Jens