[Haskell-cafe] vector-space and standard API for vectors

[wren ng thornton]

On 10/31/10 6:36 PM, Alexey Khudyakov wrote:
> On Wed, Oct 27, 2010 at 2:53 AM, wren ng thornton wrote:
>> Is there any good reason for forcing them together? Why not, use the
>> hierarchy I proposed earlier?
>> [...]
>
> Main reason is that it complicate creation of instances for types for which
> multiplication is associative and commutative more complicated.
> Programmer must write three instances instead of one and they must
> satisfy some law. It leads to code which more difficult to understand and
> contain more bug (mostly dumb).

Regardless of the class API instances must obey the law (or else have 
buggy results), so the law is uninteresting. We implicitly use such laws 
all the time, but usually we do so without having a class constraint to 
make our assumptions explicit. Isn't making assumptions explicit part of 
the reason for using a strongly typed language?

And as I mentioned previously, the burden of implementation is 2 or 3 
*lines* of code. Talking about the number of class instances people must 
write is obfuscating the fact that it's trivial to add two lines of 
code. And this is code that gets written once, in a library.

> This is tradeoff between usability and generality.

Your proposal, like so many I've seen before, is unusable because it 
lacks the necessary generality. The complexity of my proposal is 
insignificant: it requires only 2~3 lines of code, and an acknowledgment 
that there are structures other than vectorspaces.

> Modules are much less
> frequent and much less known than vector space.

Modules are more frequent than vector spaces, by definition, because 
every vector space is a module. Since you're not requiring 
Fractional(Scalar v), there isn't even any difference between them in 
the class API.

Your claim is like saying that we shouldn't have support for Applicative 
because Monads are more common. Again, there are more applicative 
functors than monads, the only cognitive overhead of having the 
Applicative class is acknowledging that there are structures other than 
monads, and adding Applicative enables a helpful style of programming 
which there is no reason to exclude.


> One possibility is to add separate type classes for left and right modules
> and require that is type is has both Module and LeftModule instances
> (*^^) == (*^)
>
>    class Module v where
>      (^*) :: v ->  Scalar v ->  v
>      (*^) :: Scalar v ->  v ->  v
>
> Of course code that is written to work with left/right modules wont work with
> associative modules.

Which my proposal fixes by making associative modules a subclass of both 
left- and right-modules.

-- 
Live well,
~wren