Operator overloading

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Operator overloading

Andreas Pokorny-2

Hi,
I just noticed the Operator overloading [1] document on glas.sf.net.
As part of my thesis work I implemented a domain specific language
framework inspired by xpressives boost::proto templates. It extends the
latter by a domain_tag, and a rule system, and allows to attach attributes
to the expression tree.

I believe you might find the library design intersting.

A user of the framework would define a domain_tag, like
linear_algebra_domain_tag, and define rules for operator overloading and
frontend functions. The rules are structure templates partially
specialized by the domain tag, a type tag discribing the operation
and the operand types. Currently only binary and unary operations are
handled.

E.g. the rule for elementwise operators like + and - which require the
parameters to have the same extends could look like that:


struct linear_algebra_domain_tag{};

template<typename OpTag,typename LT,typename RT>
struct rule<linear_algebra_domain_tag,OpTag,LT,RT,
  typename enable_if<
    mpl::and_<
      numeric::prototype::detail::requires_equal_dimension<OpTag>
      // ^ yields true for addition substracion ...
      , numeric::prototype::detail::have_equal_dimension<LT,RT>
      // ^ could check compile time extends, and attributes carring
      // meta information like whether the operand is column vector or a scalar
      >
  >::type >
    :
   defined       ///< Required to terminate the search for a domain
                 /// since the framework allows to extend an existing domain
   , mpl::true_  ///< Tells the framework, that the operation is allowed
{

  // inside the rule body, the user has to specfiy the resulf of
  // the operation, in terms of an attributed expression tree,

  // e.g. this rule yields a binary expression containing the
  // two operands and a fusion attribute map,

  typedef unification::binary_expression<
    LT
    , RT
    , typename fusion::result_of::as_map<
        typename fusion::result_of::push_front<
          typename unification::result_of::construct<OpTag,LT,RT>::type
          // ^ explained below
          , ct_pair<unification::domain_tag,linear_algebra_domain_tag>
          >::type
          // ^ attaches the domain tag type, it is possible to switch
          // into a different domain, if required.
        >::type
    > result_type;

  // a static init function has to be provdid creating the resulf of the
  // opration.

  static result_type init( LT const& left, RT const& right )
  {
    // additional runtime checking should happen here
    return result_type(
             left
             , right
             , as_map(
               fusion::push_front(
                 unification::construct<OpTag>( left, right )
                   , ct_pair<unification::domain_tag,linear_algebra_domain_tag>()
                   )
               )
             );
  };
};

I would like to explain attribute map creation in further details.
The code above uses a fusion-2 map to carry all user defined expression
attributes. Every attribute is a pair consisting of a key type tag, and
a value type. The user may use fusion::pair and ct_pair. The former
stores only an instance of the value type, and the latter does not create
any instance of the types. So the user may decide wether the information
is compile time only, or maybe both runtime and compile time.

To simplify the creation of the attribute map inside of a rule the user
may use the construct meta function. Which combines the attribute maps
of the two operands. Inside of construct the local attributes get filtered.
Then the attributes are sorted into three groups, attributes which only
occur in either of the two operands, and attributes which occur in both.
Each group of attributes, with the attached value types are then passed
to different user defined meta functions, which are supposed to update
the attribute. The user also has to specifiy whether attributes are local
or non local using a meta function.

The rule system also handles the automatic adaption of ``foreign'' types.
E.g. one could use a boost::multi_array<T,2> as matrix provided that
is_scalar<T> yields true. Rules to adapt can be specified similarly with
respect to the domain tag and the operation it occurs in.

By using SFINAE inside the operators and functions the user will never see
any "instantiated by" in their error messages as soon as illegal expressions are
detected, instead the compiler should only state that there is no matching
operand or function defined.

So far I only implemented the framework as a sort of experiment, the main
thesis code does not use it, yet. Instead it uses a striped down version
of the rule system without the domain tag, and without the fusion attribute
maps. The switch to the rule system made the operators and frontend functions
trivial to implement. I even fixed several bugs in the expression checking for
the operators, just by switching to the external rules.
As soon as I finish my thesis(3 weeks to go) I will polish and document
the library, and add further features like the so called `compilers',
which proto provides.
So feature wishes, and opinions are very welcome.

Regards
Andreas Pokorny

[1] http://glas.sourceforge.net/doc/design/operator_overloading.html


_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Operator overloading

Toon Knapen
Andreas Pokorny wrote:

> As soon as I finish my thesis(3 weeks to go) I will polish and document
> the library, and add further features like the so called `compilers',
> which proto provides.
> So feature wishes, and opinions are very welcome.



As soon as you have some documentation describing your system, please
let me know.

By the end of the week, Karl and I intend to post a little document
describing the general architecture of the
  1) expression template mechanism,
  2) dispatching mechanisms to different backends and
  3) toolboxes (on top of glas-core)

and we will post the corresponding implementation. This should totally
clarify the mechanisms inside glas.

toon
_______________________________________________
glas mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/glas