Yes, you can definitely do most of this with template metaprogramming, although, as you say it's pretty tricky. I've found that runtime generics + dispatch are easier to work with, but I don't think there's much difference in power – except in cases where you want to write code that needs to actually do the dispatch at runtime, in which case you need to resort to double dispatch or something like that in C++.
On Sun, Jul 20, 2014 at 5:09 PM, Francesco Biscani <bluesca...@gmail.com> wrote: > Hello Stefan, > > thanks for the explanations, this all looks really interesting to me. > > On 19 July 2014 22:10, Stefan Karpinski <ste...@karpinski.org> wrote: >> >> This can be pretty straightforwardly handled with multiple dispatch >> promotion in a parametric type system. Similar things are done in real code >> regularly in Julia. Although I'm not going to try to define these >> particular types, the polynomial, power series, and finite field example is >> quite possible given appropriate type definitions – people have done similar >> things <http://acooke.org/cute/FiniteFiel1.html>. An example that >> already works and is similar in spirit, is figuring out that a >> Complex{BigInt} plus a Vector{Rational{Int}} should be a >> Vector{Complex{Rational{BigInt}}}. This falls out of a surprisingly small >> set of generic function methods and promotion rules (which are just >> methods): >> >> julia> big(3)^100*im + [1, 1//2, 2] >> 3-element Array{Complex{Rational{BigInt}},1}: >> 1//1+515377520732011331036461129765621272702107522001//1*im >> 1//2+515377520732011331036461129765621272702107522001//1*im >> 2//1+515377520732011331036461129765621272702107522001//1*im >> >> > It's funny because I have been thinking about this for quite a long time > from a modern C++ perspective, and I had come to the conclusion that with > constructs like std::enable_if you can get to these results with template > metaprogramming in C++11. The tricky bit is to write arithmetic operators > that are generic but do not "swallow up" every type. In this specific case, > you would have the Vector's operator+ kick in instead of the Complex's one > (somewhere the Vector's operator+ should be defined to have a "higher rank" > than the operator+ of Complex), then you would need to deduce the common > type from Complex{BigInt} + Complex{Rational{...}} (possibly via > decltype()), and proceed to a recursion down in the type hierarchy. Of > course as you point out you would need all the ancillary functions to > actually perform the conversions from one type to the other. > > All this would entail quite a bit of template trickery, but I find it > interesting that it could be implemented all at compile time. > > (I have a primitive prototype version of something like this implemented > in a project of mine, hopefully eventually I will get around to do it > properly :) > > Anyway, cheers for the interesting discussion. > > Francesco. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
