IndexedCollection Usage

[callendorph]

Hi,

I've implemented a basic GSL vector wrapper and now I'm working on integrating it with the IndexedCollection. It seems to me like this adds some nice features - namely a default to-seq implementation which allows the GVector type to take advantage of the many existing Seq methods.

I've pushed this change in this branch :

https://github.com/callendorph/lbstanza-gsl/tree/issues/indexcol_gvector

This implementation seems to compile but when I try to compile the tests, I get the following errors:

$> stanza build gsl-tests
tests/GVector_tests.stanza:201.10: Ambiguous call to overloaded function sum with arguments of type
(GVector). Possibilities are:
  sum: GVector -> Double at src/GVector.stanza:216.12
  sum: Seqable<Double> -> Double in package core
tests/GVector_tests.stanza:220.10: Ambiguous call to overloaded function maximum with arguments of
type (GVector). Possibilities are:
  maximum: GVector -> Double at src/GVector.stanza:243.12
  maximum: <?V0> . Seqable<?V0&Comparable<?>> -> V0 in package core
tests/GVector_tests.stanza:225.6: Ambiguous call to overloaded function maximum with arguments of
type (GVector). Possibilities are:
  maximum: GVector -> Double at src/GVector.stanza:243.12
  maximum: <?V0> . Seqable<?V0&Comparable<?>> -> V0 in package core
tests/GVector_tests.stanza:233.10: Ambiguous call to overloaded function minimum with arguments of
type (GVector). Possibilities are:
  minimum: GVector -> Double at src/GVector.stanza:246.12
  minimum: <?V0> . Seqable<?V0&Comparable<?>> -> V0 in package core
tests/GVector_tests.stanza:238.6: Ambiguous call to overloaded function minimum with arguments of
type (GVector). Possibilities are:
  minimum: GVector -> Double at src/GVector.stanza:246.12
  minimum: <?V0> . Seqable<?V0&Comparable<?>> -> V0 in package core

So for the methods sum, maximum, and minimum - I have provided functions that leverage the GSL library. I think these will likely be more performant but I haven't tested this yet.

From what I can tell the sum, maximum, and minimum methods in core are defined as defn functions. If these were defmulti on some type - then I could override them from GVector with defmethod. But implemented as functions - I'm not sure how to do that. It seems like the interface is set in stone for the case where they are defn functions.

Thoughts ? Was the choice to make them defn intentional ?

[CuppoJava]

Hi Carl!

That sounds like a good reason to turn the sum, maximum, minimum functions into multis instead. I will do that.

This is a good use case for defmulti. Historically, we've been more cautious about defining things as defmulti instead of defn because it's easy to go from defn to defmulti, but much more difficult going the other way.

[callendorph]

Out of curiosity, what is the cost associated with defmulti vs defn in this case ?

In C, to do the same kind of virtual functions usually requires a switch case or a lookup table. C++ has some other
more or less similar implementation.

Is the defmulti in stanza able to determine which method to use at compile time or does it also incur the same kind of costs at runtime?

[CuppoJava]

If the compiler can tell that you are calling maximum with a GVector, then it will turn it into a direct call to that method. For example: if you've directly annotated the variable with the type GVector, or if you pass that variable to some function that requires it to be a GVector, then the compiler can deduce that it is indeed a GVector.

If the method is short enough to be inlined, the body of the method will even be inlined so the function call overhead is entirely eliminated.

If you are writing very general code that operates on e.g. Seqable, then there will be a runtime branch that dispatches to the appropriate method. This dispatch is about the cost of one memory load + two branch instructions.

[callendorph]

Cool - thank you!