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

[Chris Dams]

Dear all,

While looking at some of my code that no longer compiles under the new
tinfo() system I started wondering about the new system for
return_type_tinfo(). As this system always was always more or less
separated from the rest of the type system there is as such no reason to
remove it along with the revision of the tinfo() system. In fact, this
has serious disadvantages:
Why do all non-commutative symbols automatically get the same
return_type_tinfo-value? What if A and B represent matrices in the same
space and C is a matrix in a different space? Should A*C*B not get
simplified to (A*B)*C then? Same question for functions. Why is it no
longer possible to define your own function with the same
return_type_tinfo as, say, Dirac matrices of a particular representation
label? The fact that in ncmul::eval it is necessary to check for
Dirac/color objects indicates bad design.

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.

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

Best,
Chris