Glas List: Re: [glas] concepts, algorithms etc

From: Andrew Lumsdaine (lums_at_[hidden])
Date: 2005-03-11 10:56:54

This question raises an important issue regarding generic library 
development.  Designing concepts (and designing for genericity) is not 
the same as designing for base classes.  That is, a concept hierarchy 
should reflect the absolute *minimum* amount of functionality necessary 
for the algorithms of interest to operate (and to operate efficiently). 
  This allows each algorithm to work with the maximum number of actual 
types.

The idea is not to create a concept as a "grand unified type 
specification" that includes all possible functionality and then write 
all algorithms to take the same types.  If an algorithm is specified 
with unnecessary requirements, it will limit its range of 
applicability.  That is, one wants a set of algorithms that look likes:

template <typename Monoid>
void foo (Monoid& z, const Monoid& y, const Monoid& x);

template <typename Field>
void bar (Field& z, const Field& y, const Field& x);

template <typename VectorSpace>
void baz(VectorSpace& z, const VectorSpace& y, const VectorSpace& x);

template <typename HilbertSpace>
void zip(HilbertSpace& z, const HilbertSpace& y, const HilbertSpace& x);

Specifying all of these algorithms in terms of the type with the most 
requirements (e.g,. HilbertSpace) would mean that foo() could not be 
correctly used with types that model Monoid but not HilbertSpace.

Regards,
Andrew Lumsdaine

On Mar 11, 2005, at 4:23 PM, David Abrahams wrote:

>> My question is: why do we need a VectorSpace concept?
>
> Are there algorithms/functions you'll be implementing that actually
> require only Vector Space, but not Linear Algebra?  If so, you will
> overconstrain their arguments in the specification by using Linear
> Algebra in the requirements.