proposals

Dear List,

I am hesitating between two conceptual systems for glas.
None of them is ideal, but we have to make a choice and
perhaps someone 
comes up with a better idea.

The idea is to use Concept C++, but also provide a working
system for a 
C++ compiler.

I have the following concepts (among others)

Expression
ScalarExpression: e.g. double
VectorExpression: e.g. result_type of add(vector,vector)
DenseVectorExpression: e.g. dense_vector<double>

and
Collection
ScalarCollection: e.g. double
VectorCollection
DenseVectorCollection: e.g. dense_vector<double>

The Expression and Collection concepts are set up in a tree
fashion. For 
each Expression, there is a corresponding Collection
(one-one 
correspondance).

The root is Expression/Collection with two children:
* ScalarExpression/ScalarCollection
* VectorExpression/VectorCollection

VectorExpression/vectorCollection has one child:
* DenseVectorExpression/DenseVectorCollection

The difference between expression and collection lies in
that an 
expression is not mutable.

OK. So far the basics. Using Concept C++, these can be used
to dispatch 
an expression like

assign( v, add( x, y ) )

to the most suitable implementation, following the tree
structure of
expression and collection. I do not give the details here.

For the C++ compiler, this is more tricky:
I see two possibilities:

A) Use meta programming to examine an expression.
For each type, we can ask questions about where we are in
the concept 
tree. In the above example,

concept_tag< dense_vector<double> >::type ==
dense_vector_collection_tag

concept_tag< double >::type == scalar_collection_tag

For the dispatching, it might be useful to know which type
of expression 
we are working with, e.g.

which_kind< vector_expression_tag,
dense_vector<double> >::type == 
dense_vector_expression_tag

which_kind< collection_tag, dense_vector_<double>
>::type == 
vector_collection_tag

The which_kind meta function selects the concept that is a
child in the 
concept tree.

B) Use Bartan-Nackman trick

For each concept, we provide a type, e.g.

template <typename E>
struct dense_vector_expression
: vector_expression<E>
{
...
} ;

All GLAS types inherit from a concept type that can be used
in 
dispatching, e.g.

template <typename T>
class dense_vector
: public dense_vector_collection< vector<T> >
, public dense_vector_expression< vector<T> >
{
 ...
} ;

This system is very close to the concept c++ concept system
and 
therefore I like it very much, but the disadvantage is that
built-in 
types do not have this mechanism: e.g.

class double
: public scalar_expression<double>
, public scalar_collection<double>
{
 ...
} ;

So, we should define glas::double, glas::complex, glas::int
etc.

System B is relatively easy to put together. With system A,
the GLAS 
user can use his own classes in GLAS whithout having to use
the Barton 
and Nackman trick for his own classes, and built-in types
perfectly fit 
into the system. If we choose A, we should use this also
with Concept 
C++, otherwise we have two completely different systems,
which is overkill.

I hope my explanation is clear. It is rather technical
matter.

Thanks for your reactions.

Karl

Disclaimer: http
://www.kuleuven.be/cwis/email_disclaimer.htm

_______________________________________________
glas mailing list
glaslists.boost.org
http
://lists.boost.org/mailman/listinfo.cgi/glas

proposals

Thread: proposals