Re: Considering adding a "dispatch" function for compile-time polymorphism

[Carnë Draug]

On 18 June 2014 00:48, David Spies <address@hidden> wrote:
>
> 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:
>
> 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.

This sounds like a really useful thing. I was hoping for such a thing
for some time now (although I guess not enough to actually implement
it myself). Well done.

Carne