Re: [boost] [boost:proto] adding new tags

From: Maurizio Vitale (maurizio.vitale_at_[hidden])
Date: 2007-05-19 08:58:53

On May 19, 2007, at 12:02 AM, Gottlob Frege wrote:

> On 5/8/07, Maurizio Vitale <mav_at_cuma.polymath-solutions.lan> wrote:
>>
>> Suppose I needed a new tag for representing some high-level  
>> concept that I do not want
>> to express in terms of C++ operators [it could be a get_bit(N)  
>> operation that has very
>> different implementation when for my numbers the unserlyining  
>> implementation is a
>> builtin type or a GMP big int]
>>
>> Here's my code for adding a binary operator my_plus:
>>
>
> For us new to proto, can you give an example of your DSEL in use where
> my_plus is used?
>
> ie is it:
>
> int a;
> int b;
>
> int c = ...my_plus....
>
> what's it look like in use?
>

Suppose you have objects that derives from proto::terminal, like  
my_int in my previous posts.
Given the declarations:

        my_int<4> i=2;
        my_int<8> j=40;

You want to be able to write something like:
        i = my_plus(i,j);

Granted, you'd probably wouldn't do this for my_plus, as you have an  
operator+ that looks nicer.
What I need the ability of defining new "functions" for is for things  
like
sign(expr) - returns the sign of an expression
mask(expr, left, right) - return EXPR with bits outside the range  
left..right zeroed.
etc.

The reason I want to represent those "high" [higher than C++  
operations] concepts is that their implementation
is potentially very different. For instance extracting the sign from  
a builtin type is not the same as extracting the sign from a fixed- 
point number
and it is certainly not the same as extracting it from a GNU multi- 
precision numbers.
Note that not necessarily a comparison w/ zero would do the right  
thing: for instance in fixed point numbers
I might decide not to sign-extend after all operations
(which has a cost) and thus you have to fin the right inner bit that  
gives you the sign.

In my application (a library of fixed-point numbers) I'll have two  
levels where proto is used. A "concrete" level
that control the user-level expressions in the way one would expect  
(similar to code I posted previously, like the example
that allows you to make all combinations containing signed numbers to  
go to signed).

And then I have a meta-level where you can talk about expressions in  
the concrete domain. For instance if
        proto::eval( i+j, concrete_context) gives you 42
I want:
        proto::eval(value(_2), meta_context(j, i+j))                   [here  
value() would be implemented as my_plus above]
to also yield 42, but:
        proto::eval(value(_2), meta_context(i, i+j))
would yield 10 [with a C-like overload management, other values are  
also possible from my library].
The reason is that the value of value(EXPR) in the meta_context is  
the value of EXPR given that it must be assigned to expression _1,  
which in the
first case is j, an 8-bit quantity and in the second case is i, a 4- 
bit quantity.
In the process of evaluating value(_2) another meta-expression will  
be evaluated:
        mask(value(_2), left(_1)-left(_2))
which does the masking when needed.
The goal is to have the equivalent of the following in the assembly  
code:
        R1 <- i
        R2 <- j
        R1 <- R1 + R2
        R1 <- R1 & 0xf
        i <- R1
for the first case and to skip the masking all together for the  
second case.

It would take longer to go into the details of the fixed-point  
application, but I hope the above gives you an idea of why I needed  
something like 'my_plus'.

It takes some time and effort to understand how proto works, but if  
you have an application that fits it is time well spent.

Regards,

                Maurizio