Glas List: Re: [glas] mapping expressions to backend

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2006-01-18 07:11:09

Andreas Pokorny wrote:
> 
> You could have both, you could attach the info about the backend to your
> types. And you could have a kind of override syntax in your expressions. 
> So for every backend a small backend tag type, and an instance of each
> of them.
> 
> struct glas_lib_tag {};
> struct atlas_lib_tag {};
> struct example_library_tag {};
> 
> const glas_tag glas_lib;
> const atlas_tag atlas_lib;
> const example_library_tag example_library;
> 
> is required. These tags then can be attached to types. E.g: 
> 
>   matrix<float,atlas_lib_tag> mat;

Great. Currently we have provided this functionality already (but we
always used the term 'attribute' instead of 'tag').

>   matrix<float> some_other_matrix; // glas_lib_tag could be the default
> 
>   mat *= some_other_matrix; 
> 
> and this expression will be evaluated using atlas. 

Indeed, here you could say that the expression needs to be evaluated
using atlas because one container clearly preferred atlas while the
other had no preference. The situation can easily get ambiguous for
instance like in the following

matrix<float,some_other_backend_tag> mat_other ;
mat_other *= mat

What backend should be used now: atlas or the 'other_backend'?
This ambiguity is a consequence of attaching the attribute describing
the preferred-backend to the container instead of the operation. Because
it's actually the operation/expression that needs to be mapped to a
backend. Attaching an attribute to an operator however is syntactically
very difficult and thus resolving in option 2 (unless you have a better
idea) in my initial mail.

> And to override that
> setting, the user could write:
>    
>   mat[example_library] *= some_other_matrix; 
> 
> and a different implementation will be used.

This is indeed another alternative for the possible syntaxes I described
for option 2. I'm not sure which syntax is the easiest and clearest.

[snip]

> 
> I would like to explain more details if you are interested in the
> backend layout imposed by basic_system. 

If you have some document describing the design, you can always mail it
to me privately.

toon