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 proposed implementation: http://hg.octave.org/octave-dspies
It's the one commented: "New "dispatch" selects template argument from
octave-value (Bug #42424, 42425)"
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:
<goog_1243807005>
http://pastebin.com/GN0am4Xb
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.