Hi all,
I proposed this idea to John and Jordi who suggested I send it out to the mailing list. (I've also mentioned it in a patch as well as in various bug reports and on my blog. I'm still figuring out where to post things to get a response).
I'd like to add a dispatch function to Octave to support "compile-time polymorphism" as Jordi says.
I'm not really adding anything new. Many of Octave's core functions already (incorrectly) implement their own ad-hoc dispatching. I'd really just like to acknowledge, correct, and consolidate the logic for it.
My motivation for this change follows (TLDR; It will help the compiler debug your code and also eliminate code duplication)
Thanks,
David
----------------------------
I noticed that many of the core functions in Octave contain code of the form:
and so on like this. Here "do_fun" is a templated method which can handle any matrix type with any element type.
This particular example was taken from the "find" method which fails to handle diagonal matrices (oops).
Jordi referred to this pattern as "compile-time polymorphism" since a function is called which takes a polymorphic type and at compile-time, generates methods for handling each possible template instantiation.
My GSoC project involves cleaning up and filling in holes in the sparse matrix implementation, and what I've found is the primary problem with sparse matrices is that people simply forget to handle them when writing their functions.
In the interest of avoiding these sorts of problems in the future (and also to make it easy to write efficient code with proper template usage), I'd like to propose adding a "dispatch" function which contains all the (correct) logic for dispatching a function call to the proper template instantiation. In this way if clients rely on the dispatch function rather than trying to write their own ad-hoc dispatch logic, they'll get a compile-time warning if their implementation doesn't support one of the four basic matrix types (Array, Sparse, DiagArray2, and PermMatrix) or any of the sixteen element types.
Finally I'd like to note that I'm not planning to go through all the core octave functions updating them to use "dispatch". Rather I simply want to provide the function for people to use in the future. Essentially from now on if you encounter a bug of the form:
Function f doesn't handle type t properly
then first try changing function f's dispatching logic to call the "dispatch" function and you'll likely get a compiler error to help you correct the bug as well as eliminate a some bad code.