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

[John W. Eaton]

Sorry about not responding to this much earlier.

I'm concerned about what the proper behavior is in the presence of type 
conversions (for example, for things like an array_value function that 
extracts a full array from a permutation matrix object).  Is it 
necessary to write functions for all types, or can some conversions 
happen automatically?

If you are checking for each specific type and dispatching, then how is 
this approach better than providing a "find" method in the octave_value 
class and using a virtual function to perform the dispatching?

jwe


On 06/20/2014 10:35 PM, Carnë Draug wrote:
> 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