Re: [boost] Interest in DSL framework

From: Andreas Pokorny (andreas.pokorny_at_[hidden])
Date: 2006-08-11 18:15:04

On Fri, Aug 11, 2006 at 09:48:08AM +0800, Joel de Guzman <joel_at_[hidden]> wrote:
> Andreas Pokorny wrote:
> 
> >> Joel, Hartmut Kaiser and I have spent a lot of time working out the 
> >> details of an expression template system that would work for xpressive, 
> >> Spirit-2 and Hartmut's Karma library. The discussions were public on 
> >> spirit-devel. Search the archives for "Spirit-2 and Subversion", 
> >> "Scanner Busines, R.I.P.", "Proto Compiler Visitors", "Fusion-ifying 
> >> proto parse trees", and "segmented fusion - a-ha!"
> >>
> >> In particular, this is the message where the strategy to unify all the 
> >> ET libraries really crystallized:
> >>
> >> http://permalink.gmane.org/gmane.comp.parsers.spirit.devel/2620
> >>
> >> It would be great if you could share your thoughts on how you would 
> >> approach these problems with your new ET library.
> > 
> > I did not yet manage to read all email, but from what I read, you seem to 
> > plan using segmented sequences to encode the complete expression tree. The 
> > framework instead stores the expression tree mainly in a fusion map.
> > But I think it makes sense to support both encoding variantes. With
> > segmented sequences attributes will not work, and probably not required. 
> 
> I guess I'm still not clear about "attributes". What are those, really?
> And why will attributes not work with segmented sequences? or not
> required?

An attribute is a compile time or compile time and runtime information
stored for an expression tree, and identified by a key type. 

E.g. a matrix data structure, could provide information about itself 
inside of attributes: 

template<typename DerivedType, typename T, typename DimensionType, typename StorageType>
struct basic_matrix 
 : public basic_expression<
   fusion::map<
// Attributes                                    and their meaning
    ct_pair<operator_tag,value_tag>                   // node is a leaf in the tree
    , ct_pair<domain_tag,linear_algebra_domain_tag>   // domain of the node
    , fusion::pair<dimension_tag,DimensionType>       // dimensiontype of the tree,
                                                      //   could be runtime dynamic dimension, or compile time constants
    , ct_pair<category_tag,matrix_tag>                // node is a matrix 
    , ct_pair<value_type_tag,T>                       // the element type of the values returned by this node 
    >
 > 
{};

This information is stored inside a container and wrapped inside key-value pairs, to 
be able to write generic rules. Rules not coupled to the attribues they process. 
So rule can simply take all attributes of either operands and combine them where possible,
or update their values/types if required and store the results inside the expression 
encoding data structure returned by the rule. 

To define an attribute one needs a key type, and some meta functions which get called by 
the rule, e.g. if an attribute occurs on both operands of a node, a combine meta function 
is called. 

My statement about attributes and segmented sequences is probably wrong. Attributes just 
need a fusion::map and rules that invoke the automated attribute processing. 

Regards
Andreas Pokorny