Re: [proto] Using a derived class as terminals in Boost.proto

[Eric Niebler]

Proto grammars and transforms handle this better than evaluators, which are
deprecated. It would pay to look into some examples that use transforms.
Sorry, that's all the advice I have time for at the moment.

\e
On Apr 14, 2016 10:33 AM, "Mathias Gaunard" 
wrote:

> I'd try to use IsVector.
> I'm not sure how to do this with a grammar (maybe someone can pitch in)
> but you could do something like this
>
> enable_if< IsVector::type> >
>
> On 14 April 2016 at 18:04, Frank Winter  wrote:
>
>> I made some progress. If I specialize struct VectorSubscriptCtx::eval
>> with Vector10, like
>>
>>
>> struct VectorSubscriptCtx
>> {
>> VectorSubscriptCtx(std::size_t i) : i_(i) {}
>>
>> template
>> struct eval
>> : proto::default_eval
>> {};
>>
>> template
>> struct eval<
>> Expr
>> , typename boost::enable_if<
>> proto::matches >
>> >::type
>> >
>> {
>> //..
>> }
>> };
>>
>> then it works (is was specialized with Vector). It also works when using
>> the Boost _ literal (match anything), like
>>
>> template
>> struct eval<
>> Expr
>> , typename boost::enable_if<
>> proto::matches >
>> >::type
>>
>>
>> However, I feel this is not good style. Can this be expressed with the
>> is_base_of trait instead?
>>
>>
>>
>>
>>
>> On 04/14/2016 10:10 AM, Mathias Gaunard wrote:
>>
>>> On 14 April 2016 at 14:43, Frank Winter >> > wrote:
>>>
>>> Hi all!
>>>
>>> Suppose you'd want to implement a simple EDSL (Embedded Domain
>>> Specific Language) with Boost.proto with the following requirements:
>>>
>>>  Custom class 'Vector' as terminal
>>>  Classes derived from 'Vector' are working terminals too, e.g.
>>> Vector10
>>>
>>> [...]
>>>
>>> template
>>> struct IsVector
>>>: mpl::false_
>>> {};
>>>
>>>
>>> template<>
>>> struct IsVector< Vector >
>>>: mpl::true_
>>> {};
>>>
>>>
>>> Surely this should be true for all types derived from Vector.
>>>
>>> template
>>> struct IsVector
>>>: mpl::false_
>>> {};
>>>
>>> template
>>> struct IsVector >::type>
>>>: mpl::true_
>>> {};
>>>
>>>
>>> ___
>>> proto mailing list
>>> proto@lists.boost.org
>>> http://lists.boost.org/mailman/listinfo.cgi/proto
>>>
>>>
>>
>> ___
>> proto mailing list
>> proto@lists.boost.org
>> http://lists.boost.org/mailman/listinfo.cgi/proto
>>
>
>
> ___
> proto mailing list
> proto@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/proto
>
>
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Using a derived class as terminals in Boost.proto

[Mathias Gaunard]

On 14 April 2016 at 15:37, Frank Winter  wrote:

>
> and still, I get basically the same error message:
>
> /home/fwinter/src/boost_1_60_0/boost/proto/context/default.hpp:121:41:
> error: no match for ‘operator+’ (operand types are ‘Vector10’ and
> ‘Vector10’)
>  BOOST_PROTO_BINARY_DEFAULT_EVAL(+, proto::tag::plus, make, make)
>
>
> It's weird since the operator+ should be there for Vector, and since I am
> importing the namespace VectorOps, it should work for derived classes. I
> don't see why it's not working.


A recent enough compiler should tell you which candidates it tried and why
they were removed due to SFINAE.
I don't have the time to try out your code at the moment but I recommend
you try to take a look at this.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Using a derived class as terminals in Boost.proto

[Frank Winter]

On 04/14/2016 10:10 AM, Mathias Gaunard wrote:

On 14 April 2016 at 14:43, Frank Winter > wrote:

Hi all!

Suppose you'd want to implement a simple EDSL (Embedded Domain
Specific Language) with Boost.proto with the following requirements:

 Custom class 'Vector' as terminal
 Classes derived from 'Vector' are working terminals too, e.g.
Vector10

[...]

template
struct IsVector
   : mpl::false_
{};


template<>
struct IsVector< Vector >
   : mpl::true_
{};


Surely this should be true for all types derived from Vector.

template
struct IsVector
   : mpl::false_
{};

template
struct IsVector >::type>
   : mpl::true_
{};




I had tried this


template<>
struct IsVector< Vector10 >
  : mpl::true_
{};


before. Same error message. Now I tried the base_of implementation


template
struct IsVector
  : mpl::false_
{};

template
struct IsVectorT>::value >::type>

  : mpl::true_
{};


and still, I get basically the same error message:

/home/fwinter/src/boost_1_60_0/boost/proto/context/default.hpp:121:41: 
error: no match for ‘operator+’ (operand types are ‘Vector10’ and 
‘Vector10’)

 BOOST_PROTO_BINARY_DEFAULT_EVAL(+, proto::tag::plus, make, make)


It's weird since the operator+ should be there for Vector, and since I 
am importing the namespace VectorOps, it should work for derived 
classes. I don't see why it's not working.


Thanks,
Frank




___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Using a derived class as terminals in Boost.proto

[Mathias Gaunard]

On 14 April 2016 at 14:43, Frank Winter  wrote:

> Hi all!
>
> Suppose you'd want to implement a simple EDSL (Embedded Domain Specific
> Language) with Boost.proto with the following requirements:
>
> Custom class 'Vector' as terminal
> Classes derived from 'Vector' are working terminals too, e.g. Vector10
>
> [...]

template
> struct IsVector
>   : mpl::false_
> {};
>
>
> template<>
> struct IsVector< Vector >
>   : mpl::true_
> {};
>
>
Surely this should be true for all types derived from Vector.

template
struct IsVector
  : mpl::false_
{};

template
struct IsVector >::type>
  : mpl::true_
{};
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Using a derived class as terminals in Boost.proto

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Using a derived class as terminals in Boost.proto

[Frank Winter]

Hi all!

Suppose you'd want to implement a simple EDSL (Embedded Domain Specific 
Language) with Boost.proto with the following requirements:


Custom class 'Vector' as terminal
Classes derived from 'Vector' are working terminals too, e.g. Vector10

Reading the manual of Boost.proto it seems the closest related example 
to this would be the 'Vector: Adapting a Non-Proto Terminal Type' example.


Modifications I did to that example:

Added 'Vector' class
Protofied Vector instead of std::vector

Here the code (compiles):


// 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
namespace mpl = boost::mpl;
namespace proto = boost::proto;
using proto::_;

class Vector;

template
struct VectorExpr;

struct VectorSubscriptCtx
{
VectorSubscriptCtx(std::size_t i)
  : i_(i)
{}

template
struct eval
  : proto::default_eval
{};

template
struct eval<
Expr
  , typename boost::enable_if<
proto::matches >
>::type
>
{
typedef typename 
proto::result_of::value::type::value_type result_type;


result_type operator ()(Expr , VectorSubscriptCtx const 
) const

{
return proto::value(expr)[ctx.i_];
}
};

std::size_t i_;
};




struct VectorGrammar : proto::or_<
proto::terminal< proto::_ >,
proto::plus< VectorGrammar, VectorGrammar>,
proto::minus< VectorGrammar, VectorGrammar>
> {};

struct VectorDomain
  : proto::domain
{};



template
struct VectorExpr
  : proto::extends
{
explicit VectorExpr(Expr const )
  : proto::extends(expr)
{}

typename proto::result_of::evalconst>::type

operator []( std::size_t i ) const
{
VectorSubscriptCtx const ctx(i);
return proto::eval(*this, ctx);
}
};




class Vector {
private:
  int sz;
  double* data;

public:
  typedef double value_type;

  explicit Vector(int sz_ = 1, double iniVal = 0.0) :
sz( sz_), data( new double[sz] ) {
for (int i = 0; i < sz; i++) data[i] = iniVal;
  }
  Vector(const Vector& vec) :
sz( vec.sz), data( new double[sz] ) {
for (int i = 0; i < sz; i++) data[i] = vec.data[i];
  }

  size_t size() const {return sz; }

  ~Vector() {
delete [] data;
  }

  double& operator[](int i) { return data[i]; }
  const double& operator[](int i) const { return data[i]; }
};



class Vector10: public Vector
{
public:
  Vector10() : Vector(10,0.0) {}
};




template
struct IsVector
  : mpl::false_
{};


template<>
struct IsVector< Vector >
  : mpl::true_
{};



namespace VectorOps
{
BOOST_PROTO_DEFINE_OPERATORS(IsVector, VectorDomain)

typedef VectorSubscriptCtx const CVectorSubscriptCtx;

template
Vector (Vector , Expr const )
{
for(std::size_t i = 0; i < arr.size(); ++i)
{
arr[i] = proto::as_expr(expr)[i];
}
return arr;
}
}



int main()
{
using namespace VectorOps;

Vector a,b,c,d;

VectorOps::assign(d, a + b );
}


// 


There's already the derived class Vector10 defined. Now - using that one 
instead of Vector


int main()
{
using namespace VectorOps;

Vector10 a,b,c,d;

VectorOps::assign(d, a + b );
}


I believe that the operators for Vector are correctly defined in the 
namespace VectorOps but the ADL doesn't kick in for the derived class.


Any idea how this can be fixed?

Thanks,
Frank




___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

[Bart Janssens]

Hi Masa,

Good to hear, good luck with your work!

Cheers,

Bart

On Fri, Jan 15, 2016 at 3:19 AM Masakatsu ITO(伊藤) 
wrote:

> Hi Bart and Boost.Proto community,
>
> Thanks to you, I made some progress on my mini-EDSL and
> have given a poster presentation at the small symposium
> of computer science in Japan to discuss about DSLs for
> scientific simulation.
>
> Although my EDSL still has lots of template errors, I hope to
> post its error-free version to GitHub before long.
>
> Best regards,
> Masa
>
>
> Masakatsu ITO
>
>
>
>
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

[伊藤]

Hi Bart and Boost.Proto community,

Thanks to you, I made some progress on my mini-EDSL and
have given a poster presentation at the small symposium
of computer science in Japan to discuss about DSLs for
scientific simulation.

Although my EDSL still has lots of template errors, I hope to
post its error-free version to GitHub before long.

Best regards,
Masa

Masakatsu ITO


On 2015年12月26日 07:11, Bart Janssens wrote:
On Fri, Dec 25, 2015 at 2:07 PM Masakatsu ITO(伊藤) 
> wrote:



Actually I tried to adapt my DiffereneceOperator type to Proto
as Proto Users Guide explains in "Adapting Existing Types to Proto".


http://www.boost.org/doc/libs/1_57_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.define_operators


I think this didn't work because the macro doesn't overload the 
function call operator.


And I wondered when it is necessary to write a code such like

calculator<  proto::terminal<  placeholder<0>  >::type  >  const  _1;


in |"The extends< > Expression Wrapper".


http://www.boost.org/doc/libs/1_57_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.customizing_expressions_in_your_domain.extends
|




This is needed to make sure the terminal is part of the calculator 
domain, if you leave out the calculator<> part you just get an 
expression in the default domain.


Wishing you a merry Christmas,
Masa


Merry Christmas to you too!

Bart


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

[伊藤]

Hi Bart,

Thank you so much for fixing my source code and giving me
this good starting point for my first mini-EDSL .
I'll try to extend grammar objects and will learn more about Proto.



You can create a proper proto terminal in your domain using:
ExprWrapper const 
opr = {{}};


Actually I tried to adapt my DiffereneceOperator type to Proto
as Proto Users Guide explains in "Adapting Existing Types to Proto".

http://www.boost.org/doc/libs/1_57_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.define_operators


And I wondered when it is necessary to write a code such like

calculator<  proto::terminal<  placeholder<0>   >::type   >  const  _1;


in |"The extends< > Expression Wrapper".

http://www.boost.org/doc/libs/1_57_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.customizing_expressions_in_your_domain.extends
| 



But I now see there's a big difference between these two ways.
although I still don't understand why .


So I'm reading your paper,
"Finite Element Assembly Using an Embedded Domain Specific Language",
Bart Janssens, Támas Bányai, Karim Limam, and Walter Bosschaerts,
Scientific Programming Volume 2015 (2015), Article ID 797325, 22 pages.

It's very interesting and helpful to me.

Wishing you a merry Christmas,
Masa


p.s. It's awfully quiet on this list, is it still the place to discuss 
Proto?



I wish there could be a place where lots of people discuss about
how to use Proto for scientific simulations.



On 2015年12月22日 20:57, Bart Janssens wrote:

Hi Masa,

The problem is that you were not really building a proto expression, 
but just calling your DifferenceOperator directly. You can create a 
proper proto terminal in your domain using:
ExprWrapper const 
opr = {{}};


Once that is done, only the deep copy compiles, but you need a proper 
grammar for evaluation to work, and a << overload for printing and 
starting evaluation. The fixed code with a small start of the grammar 
is attached.


p.s. It's awfully quiet on this list, is it still the place to discuss 
Proto?


Cheers,

Bart

On Mon, Dec 14, 2015 at 12:48 PM Masakatsu ITO(伊藤) 
> wrote:


Hello,

I'm trying to make an EDSL for finite volume method,
which translates a formula of the method into
executable code.

Now I've confirmed that such a formula

 std::cout << MyEDSL::opr( 0.1, 0.1) + 1.0 << std::endl;

can be compiled and prints out the correct answer.



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] How to customize an expression in an EDSL , so as to make a deep copy of it?

[Bart Janssens]

On Fri, Dec 25, 2015 at 2:07 PM Masakatsu ITO(伊藤) 
wrote:

>
> Actually I tried to adapt my DiffereneceOperator type to Proto
> as Proto Users Guide explains in "Adapting Existing Types to Proto".
>
>
> http://www.boost.org/doc/libs/1_57_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.define_operators
>
>
I think this didn't work because the macro doesn't overload the function
call operator.



> And I wondered when it is necessary to write a code such like
>
> calculator< proto::terminal< placeholder<0> >::type > const _1;
>
>
> in "The extends< > Expression Wrapper".
>
>
> http://www.boost.org/doc/libs/1_57_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.customizing_expressions_in_your_domain.extends
>
> 
>

This is needed to make sure the terminal is part of the calculator domain,
if you leave out the calculator<> part you just get an expression in the
default domain.



> Wishing you a merry Christmas,
> Masa
>
>
Merry Christmas to you too!

Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Paper about using Proto in FEM

[Bart Janssens]

Hi,

I have written an open-access paper about using Proto for finite element
assembly. It's roughly based on my 2013 CPPnow presentation and can be
accessed here:
http://www.hindawi.com/journals/sp/2015/797325/

Cheers,

Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Clang compile times

[Bart Janssens]

On Thu, Nov 21, 2013 at 11:19 PM, Eric Niebler e...@boostpro.com wrote:
 Ugh, this is terrible news. If you have a self-contained repro
 (preprocessed translation unit), please file a clang bug. They'll take a
 regression of this magnitude seriously.

OK, I added a bug at:
http://llvm.org/bugs/show_bug.cgi?id=18055

Cheers,

Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Clang compile times

[Eric Niebler]

On 11/20/2013 02:36 AM, Bart Janssens wrote:
 Hello,
 
 I recently upgraded the OS and XCode on my Mac, resulting in the
 following clang version:
 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn).
 The previous version was Apple LLVM version 4.2 (clang-425.0.24)
 (based on LLVM 3.2svn)
 
 The new version is about 4 times slower when compiling proto code, but
 only uses about half as much RAM. Does anyone here know if this may be
 due to some clang setting that I can revert back? I'd like to use more
 RAM again and compile faster.

Ugh, this is terrible news. If you have a self-contained repro
(preprocessed translation unit), please file a clang bug. They'll take a
regression of this magnitude seriously.

Thanks,
Eric
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Clang compile times

[Bart Janssens]

Hello,

I recently upgraded the OS and XCode on my Mac, resulting in the
following clang version:
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn).
The previous version was Apple LLVM version 4.2 (clang-425.0.24)
(based on LLVM 3.2svn)

The new version is about 4 times slower when compiling proto code, but
only uses about half as much RAM. Does anyone here know if this may be
due to some clang setting that I can revert back? I'd like to use more
RAM again and compile faster.

Cheers,

Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Holding children by copy or reference

[Luc Danton]

On 2013-09-30 13:54, Mathias Gaunard wrote:

Hi,

A while ago, I recommended to set up domains so that Proto contains its
children by value, except for terminals that should either be references
or values depending on the lvalue-ness. This allows to avoid dangling
reference problems when storing expressions or using 'auto'.
I also said there was no overhead to doing this in the case of Boost.SIMD.

After having done more analyses with more complex code, it appears that
there is indeed an overhead to doing this: it confuses the alias
analysis of the compiler which becomes unable to perform some
optimizations that it would otherwise normally perform.

For example, an expression like this:
r = a*b + a*b;

will not anymore get optimized to
tmp = a*b;
r = tmp + tmp;

If terminals are held by reference, the compiler can also emit extra
loads, which it doesn't do if the the terminal is held by value or if
all children are held by reference.

This is a bit surprising that this affects compiler optimizations like
this, but this is replicable on both Clang and GCC, with all versions I
have access to.

Therefore, to avoid performance issues, I'm considering moving to always
using references (with the default domain behaviour), and relying on
BOOST_FORCEINLINE to make it work as expected.
Of course this has the caveat that if the force inline is disabled (or
doesn't work), then you'll get segmentation faults.


Hello,

as a heads-up, I've made it a habit in C++11 to structure generic 
'holders' or types as such:


templatetypename Some, typename Parameters, typename Here
struct foo_type {
// Encapsulation omitted for brevity

foo_type(Some some, Parameters parameters, Here here)
// Don't use std::move here
: some(std::forwardSome(some))
, parameters(std::forwardParameters(parameters))
, here(std::forwardHere(here))
{}

Some some;
Parameters parameters;
Here here;

/* How to use the data members: */

/* example observer */
Some peek() { return some; }
/* can be cv-qualified */
Some const peek() const { return some; }
/* can be ref-qualified */
Parameters fetch() 
{ return std::forwardParameters(parameters); }

/* meant to be called several times per lifetimes
decltype(auto) bar()
  /* can be cv- and ref-qualified indifferently */
{
// don't forward, don't move
return qux(some, parameters, here);
}

/* meant to be called at most once per lifetime */
void zap()
{
// forwarding is a low-hanging optimization
blast(std::forwardSome(some));
}
};

templatetypename Some, typename Parameters, typename Here
foo_typeSome, Parameters, Here foo(Some some
 , Parameters parameters
 , Here here)
{
return {
std::forwardSome(some)
, std::forwardParameters(parameters)
, std::forwardHere(here)
 };
}

Note that either auto f = foo(0, 'a', c); or auto f = foo(0, 'a', 
c); is fine, with no dangling reference. Rvalues arguments to the foo 
factory are stored as values, lvalue arguments as lvalue references. You 
can still ask for rvalue reference members 'by hand' (e.g. 
foo_typeint, int, int f { std::move(i), std::move(i), 
std::move(i) };, although I don't really use that functionality (save 
with std::tuple, but that's another story).


For something like auto f = foo(1, 2, 3); auto g = foo(f, 4, 5); then
inside g the ints would be held as values, and f as a reference. If 
std::move(f) would have been used, it would have been moved inside a 
copy internal to g. In terms of an EDSL, then both nodes and terminals 
can be held indifferently as references or values, depending on how they 
are passed as arguments.


As I've said, I use this technique as a default and I do have a 
run-off-the-mill lazy-eval EDSL where I put it to use. I cannot report 
bad things happening (incl. with libstdc++ debug mode, and checking with 
Valgrind). IME, when looking at the generated code, the compiler can see 
through most of the time. I have to warn though that I do not use the 
technique for the sake of efficiency. I simply find it the most 
convenient and elegant.


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Holding children by copy or reference

[Bart Janssens]

On Tue, Oct 1, 2013 at 12:59 AM, Mathias Gaunard
mathias.gaun...@ens-lyon.org wrote:
 To clarify, in terms of performance, from best-to-worst:
 1) everything by reference: no problem with performance (but problematic
 dangling references in some scenarios)
 2) everything by value: no CSE or other optimizations
 3) nodes by value, terminals by reference: no CSE or other optimizations +
 loads when accessing the terminals

Just out of interest: would holding the a*b temporary node by rvalue
reference be possible and would it be of any help?

Cheers,

Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Holding children by copy or reference

[Eric Niebler]

On 10/1/2013 12:05 AM, Bart Janssens wrote:
 On Tue, Oct 1, 2013 at 12:59 AM, Mathias Gaunard
 mathias.gaun...@ens-lyon.org wrote:
 To clarify, in terms of performance, from best-to-worst:
 1) everything by reference: no problem with performance (but problematic
 dangling references in some scenarios)
 2) everything by value: no CSE or other optimizations
 3) nodes by value, terminals by reference: no CSE or other optimizations +
 loads when accessing the terminals
 
 Just out of interest: would holding the a*b temporary node by rvalue
 reference be possible and would it be of any help?

Possible in theory, yes. In practice, it probably doesn't work since
proto-v4 is not C++11 aware. But even if it worked, it wouldn't solve
anything. Rvalue refs have the same lifetime issues that (const) lvalue
refs have. The temporary object to which they refer will not outlive the
full expression.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Holding children by copy or reference

[Mathias Gaunard]

Hi,

A while ago, I recommended to set up domains so that Proto contains its 
children by value, except for terminals that should either be references 
or values depending on the lvalue-ness. This allows to avoid dangling 
reference problems when storing expressions or using 'auto'.

I also said there was no overhead to doing this in the case of Boost.SIMD.

After having done more analyses with more complex code, it appears that 
there is indeed an overhead to doing this: it confuses the alias 
analysis of the compiler which becomes unable to perform some 
optimizations that it would otherwise normally perform.


For example, an expression like this:
r = a*b + a*b;

will not anymore get optimized to
tmp = a*b;
r = tmp + tmp;

If terminals are held by reference, the compiler can also emit extra 
loads, which it doesn't do if the the terminal is held by value or if 
all children are held by reference.


This is a bit surprising that this affects compiler optimizations like 
this, but this is replicable on both Clang and GCC, with all versions I 
have access to.


Therefore, to avoid performance issues, I'm considering moving to always 
using references (with the default domain behaviour), and relying on 
BOOST_FORCEINLINE to make it work as expected.
Of course this has the caveat that if the force inline is disabled (or 
doesn't work), then you'll get segmentation faults.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Holding children by copy or reference

[Eric Niebler]

On 9/30/2013 1:54 PM, Mathias Gaunard wrote:
 Hi,
 
 A while ago, I recommended to set up domains so that Proto contains its
 children by value, except for terminals that should either be references
 or values depending on the lvalue-ness. This allows to avoid dangling
 reference problems when storing expressions or using 'auto'.
 I also said there was no overhead to doing this in the case of Boost.SIMD.
 
 After having done more analyses with more complex code, it appears that
 there is indeed an overhead to doing this: it confuses the alias
 analysis of the compiler which becomes unable to perform some
 optimizations that it would otherwise normally perform.
 
 For example, an expression like this:
 r = a*b + a*b;
 
 will not anymore get optimized to
 tmp = a*b;
 r = tmp + tmp;

Interesting!

 If terminals are held by reference, the compiler can also emit extra
 loads, which it doesn't do if the the terminal is held by value or if
 all children are held by reference.
 
 This is a bit surprising that this affects compiler optimizations like
 this, but this is replicable on both Clang and GCC, with all versions I
 have access to.

It's very surprising. I suppose it's because the compiler can't assume
equasional reasoning holds for some user-defined type. That's too bad.

 Therefore, to avoid performance issues, I'm considering moving to always
 using references (with the default domain behaviour), and relying on
 BOOST_FORCEINLINE to make it work as expected.

Why is FORCEINLINE needed?

 Of course this has the caveat that if the force inline is disabled (or
 doesn't work), then you'll get segmentation faults.

I don't understand why that should make a difference. Can you clarify? A
million thanks for doing the analysis and reporting the results, by the way.

As an aside, in Proto v5, terminals and intermediate nodes are captured
as you describe by default, which means perf problems. I still think
this is the right default for C++11, and for most EDSLs. I'll have to be
explicit in the docs about the performance implications, and make it
easy for people to get the by-ref capture behavior when they're ok with
the risks.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Holding children by copy or reference

[Mathias Gaunard]

On 30/09/13 08:01, Eric Niebler wrote:


Therefore, to avoid performance issues, I'm considering moving to always
using references (with the default domain behaviour), and relying on
BOOST_FORCEINLINE to make it work as expected.


Why is FORCEINLINE needed?


The scenario is

terminal a, b, c, r;

auto tmp = a*b*c;
r = tmp + tmp;

Assuming everything is held by reference, when used in r, tmp will refer 
to a dangling reference (the a*b node).


If everything is inlined, the problem may be avoided because it doesn't 
require things to be present on the stack.


Of course, it's quite hacky.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Holding children by copy or reference

[Eric Niebler]

On 9/30/2013 11:08 AM, Mathias Gaunard wrote:
 On 30/09/13 08:01, Eric Niebler wrote:
 
 Therefore, to avoid performance issues, I'm considering moving to always
 using references (with the default domain behaviour), and relying on
 BOOST_FORCEINLINE to make it work as expected.

 Why is FORCEINLINE needed?
 
 The scenario is
 
 terminal a, b, c, r;
 
 auto tmp = a*b*c;
 r = tmp + tmp;
 
 Assuming everything is held by reference, when used in r, tmp will refer
 to a dangling reference (the a*b node).
 
 If everything is inlined, the problem may be avoided because it doesn't
 require things to be present on the stack.

Yikes! You don't need me to tell you that's UB, and you really shouldn't
encourage people to do that.

You can independently control how intermediate nodes are captured, as
opposed to how terminals are captured. In this case, you want a,b,c held
by reference, and the temporary a*b to be held by value. Have you
tried this, and still found it to be slow?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] How to prevent function to be called for every evaluation of an expression?

[Ole Svensson]

Hi,



for educational purposes I am implementing an EDSL for vector arithmetic and lazy evaluation which works quite nice (and fast) so far. But when I compile something like:



Vector a, b, c;

a = b + c + dotProduct(b, c);



the result is computed correctly but dotProduct() is called for every component of the vector which is clearly undesirable. I thought of solving this by using transforms to pre-evaluate scalar-valued sub-expressions but when I call

proto::display_expr( b + c + dotProduct(b,c) );

the AST that is printed does not include some kind of function node but the return value of dotProduct(b,c) --i.e., some number.



So my questions are:

a) Why is dotProduct(b,c) still evaluated for every component and

b) how can I prevent this from happening for *every* scalar-valued function? (I.e., I do not want to declare *specific* functions as terminals in my DSL.)



Many thanks and best regards

Ole



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] How to prevent function to be called for every evaluation of an expression?

[Ole Svensson]

 What exactly is dotProduct? Is it a C++ function? If so, it will just
 get evaluated and the AST will contain the result of the evaluation.
 In that case I would expect it to only get evaluated once. How are you
 checking that it gets called multiple times? You might try setting a
 breakpoint in dotProduct and check where it gets called from.

Hi Bart,

I must apologize: because of my messy prototype code layout I forgot that -- in 
order to benchmark my program -- I evaluated the expression several thousand 
times; hence the function dotProduct got called that often.
But of course you are correct: for every evaluation of the vector expression it 
gets called only once.

Thank you very much!
Ole
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

[Eric Niebler]

On 6/16/2013 11:59 AM, Agustín K-ballo Bergé wrote:
 On 15/06/2013 10:59 p.m., Eric Niebler wrote:
 - Some specific uses of Proto actions in constant expressions fail. GCC
 reports an ambiguity with ref-qualifiers in the following scenario:
 
  struct foo
  {
  int bar() 
  { return _bar; }
  //~ int bar() 
  //~ { return static_castint(_bar); }
  constexpr int const bar() const 
  { return _bar; }
  constexpr int const bar() const 
  { return static_castint const(_bar); }
 
  int _bar;
  };
 
  foo().bar();
 
For that to work correctly, the 4 overloads need to be provided.
 Huh. According to the standard, or according to gcc? I won't work around
 a bug in a compiler without filing it first.

 
 I got a thorough explanation on the subject from this SO question:
 http://stackoverflow.com/questions/17130607/overload-resolution-with-ref-qualifiers
 . The answer confirms this is a GCC bug, and hints to a better
 workaround that would retain constexpr functionality. I may pursue this
 alternative workaround if I ever get to play with the constexpr side of
 Proto v5 (that is, if I use it in a place other than next to an `omg` or
 `srsly` identifier :P).
 
 Another GCC bug (as far as I understand) is that instantiations within
 template arguments to a template alias are completely ignored when the
 aliased type does not depend on those, thus breaking SFINAE rules. I
 have attached a small code sample that reproduces this issue.

Thanks for your research. When I get a chance, I'll check gcc's bugzilla
to see if they have been filed already, unless you beat me to it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

[Agustín K-ballo Bergé]

On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:

On 14/06/2013 11:06 p.m., Eric Niebler wrote:


(Sorry for the top-posting. I'm away from my computer.)

The repository *is* compilable, if your compiler is clang built from
trunk. I suspect there are bugs in Proto, gcc, and clang, and sorting
it all out will be fun.

Thanks for your patch. I'll apply it as soon as I can.

Eric


That's the green light I was expecting to start picking Proto v5 at GCC.
I just got the first test compiling and passing successfully
(action.cpp). I have pushed all the changes to my fork of the
repository, so if you are interested keep an eye on it.

Even after disabling the substitution_failure machinery (to get the full
instantiation spew), going through the compiler output is mind
bending... My respects to you, sir!





The fork of Proto v5 at https://github.com/K-ballo/proto-0x correctly 
compiles and passes (almost*) all test cases and examples with GCC 
4.8.1. There are two caveats:


- GCC does not allow the use of `this` within noexcept specifications, 
so those are disabled. This is a bug in GCC (reported by Dave Abrahams 
here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869)


- Some specific uses of Proto actions in constant expressions fail. GCC 
reports an ambiguity with ref-qualifiers in the following scenario:


struct foo
{
int bar() 
{ return _bar; }
//~ int bar() 
//~ { return static_castint(_bar); }
constexpr int const bar() const 
{ return _bar; }
constexpr int const bar() const 
{ return static_castint const(_bar); }

int _bar;
};

foo().bar();

  For that to work correctly, the 4 overloads need to be provided. 
This, in turn, means that non-const rvalues (?) cannot be used in 
constant expressions since constexpr implies const (in C++11, not 
anymore in C++14). Anyway, this is more than I can digest at the moment.


(*) the bit failing to compile is a use of Proto actions as a constant 
expression [the `omg` case at everywhere.cpp], due to the issue with 
ref-qualifier overloads.


Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

[Agustín K-ballo Bergé]

On 15/06/2013 10:59 p.m., Eric Niebler wrote:

On 13-06-15 03:40 PM, Agustín K-ballo Bergé wrote:

On 15/06/2013 03:43 a.m., Agustín K-ballo Bergé wrote:

On 14/06/2013 11:06 p.m., Eric Niebler wrote:

- Some specific uses of Proto actions in constant expressions fail. GCC
reports an ambiguity with ref-qualifiers in the following scenario:

 struct foo
 {
 int bar() 
 { return _bar; }
 //~ int bar() 
 //~ { return static_castint(_bar); }
 constexpr int const bar() const 
 { return _bar; }
 constexpr int const bar() const 
 { return static_castint const(_bar); }

 int _bar;
 };

 foo().bar();

   For that to work correctly, the 4 overloads need to be provided.


Huh. According to the standard, or according to gcc? I won't work around
a bug in a compiler without filing it first.


I do not know, this little experiment has got me re-reading the standard 
back and forth, but I am not that fluent in standardeese. I'm still 
researching this and a few other of the issues.



This,
in turn, means that non-const rvalues (?) cannot be used in constant
expressions since constexpr implies const (in C++11, not anymore in
C++14). Anyway, this is more than I can digest at the moment.

(*) the bit failing to compile is a use of Proto actions as a constant
expression [the `omg` case at everywhere.cpp], due to the issue with
ref-qualifier overloads.


I see you included all of these fixes in your one pull request. I'll
need to go through this carefully and file compiler bugs where
necessary.


I did not, or if I did it was unintentional. I only wanted to submit the 
first change I did, the one that fixes the duplicated constexprs. That's 
the single one I'm confident enough that has to be applied. Alas, the 
last change I did silences a GCC warning, so that one is another good 
candidate (after refactoring to your coding style). The others probably 
won't fit your coding style anyways, plus some are even incorrect and 
further reverted/fixed. They are only intended to be a guide of what has 
to be changed to please GCC.



I also want to use BOOST_WORKAROUND if we actually include
any temporary workarounds in the code. I say temporary because I have
every intention of ripping out all workarounds once the bugs actually
get fixed. I intend to keep this code as clean as possible.



I would appreciate if we could discuss (off-list if appropriate) all 
these changes I've done as you go through them, whenever you have the 
time. I am particularly interested in determining whether the code is 
standard conforming, or whether they are the result of bugs in either 
GCC or Clang.



A million thanks for your work. It's a huge help.



My pleasure. This has been a productive learning experience for me (one 
that has not yet ended I hope).


Regards,
--
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Proto v5

[Eric Niebler]

I've made no effort so far to port Proto v5 to any compiler other than clang. 
I'm sure it would be a big job. I welcome any contributions. Otherwise, it'll 
get ported eventually, but probably not before I get the API settled.

Eric


Sent via tiny mobile device

-Original Message-
From: Agustín K-ballo Bergé kaball...@hotmail.com
Sender: proto proto-boun...@lists.boost.orgDate: Fri, 14 Jun 2013 16:19:23 
To: Discussions about Boost.Proto and DSEL designproto@lists.boost.org
Reply-To: Discussions about Boost.Proto and DSEL design
proto@lists.boost.org
Subject: [proto] Proto v5

Hi,

I watched the C++Now session about Proto v5, and now I want to play with 
it. I do not have the luxury of a Clang build from trunk, but I do have 
GCC 4.8.1 which should do pretty well.

I cloned the repository at https://github.com/ericniebler/proto-0x/. 
After jumping a few hoops, I am now left with tons of instances of the 
same errors:

- error: no type named 'proto_grammar_type' in ...
  using type = typename Ret::proto_grammar_type(Args...);

- error: no type named 'proto_action_type' in ...
  using type = typename Ret::proto_action_type(Args...);

For at least some cases, those are clear errors since the Ret type 
represents an empty structs (e.g. `not_`).

What is going on? What should I be doing to get Proto v5 to compile?

Regards,

-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] problems with proto::matches

[Eric Niebler]

On 12/13/2012 4:51 AM, Thomas Heller wrote:
 Hi,
 
 I recently discovered a behavior which i find quite odd:
 proto::matchesExpression, Grammar::type fails when Expression is not a
 proto expression. I would have expected that it just returns false in
 this case. What am I missing. Patch is attached for what i think would
 be a better behavior of that meta function.

Hi Thomas,

Thanks for the patch. Pros and cons to this. Pro: it works in more
situations, including yours. (Could you tell me a bit about your
situation?) Also, the implementation is dead simple and free of extra
TMP overhead.

Cons: Someone might expect a non-Proto type to be treated as a terminal
of that type and be surprised at getting a false where s/he expected
true (a fair assumption since Proto treats non-expressions as terminals
elsewhere; e.g., in its operator overloads). It slightly complicates the
specification of matches. It is potentially breaking in that it changes
the template arity of proto::matches. (Consider what happens if someone
is doing mpl::quote2proto::matches.)

I'm inclined to say this is not a bug and that it's a prerequisite of
matches that Expression is a proto expression. If you want to use it
with types that aren't expressions, you can already do that:

  templateclass MaybeExpr, class Grammar
  struct maybe_matches
: mpl::if_ proto::is_exprMaybeExpr
  , proto::matchesMaybeExpr, Grammar
  , mpl::false_
  ::type
  {};

Would the above work for you? I realize that's more expensive than what
you're doing now. :-(

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Transform result_of nightmare and preserving terminal identity

[Mathias Gaunard]

On 31/10/12 21:28, Agustín K-ballo Bergé wrote:


Quoting from my original mail, what I want is to replace the following
geometric vector expression:

 p = q + r;

by

 p[0] = q[0] + r[0],
 p[1] = q[1] + r[1],
 ...,
 p[N] = q[N] + r[N],
 p;

It **can** be done with a transform and that's what I did. The optimized
proto expression evaluates ~33% faster than the original proto expression.


You could also evaluate the expression directly instead of rebuilding a 
new expression to evaluate.


That would probably increase compilation performance.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Transform result_of nightmare and preserving terminal identity

[Agustín K-ballo Bergé]

On 16/10/2012 03:50 p.m., Agustín K-ballo Bergé wrote:

On 16/10/2012 02:22 a.m., Eric Niebler wrote:

Hi Agustín,

This is just a quick note to let you know that I'm currently at the
standard committee meeting in Portland, and that I'll be unable to look
until this until I get back next week.



Thank you for letting me know.

Agustín K-ballo Bergé.-
http://fusionfenix.com

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto




For future reference, my issue was resolved at StackOverflow. You can 
find it here 
http://stackoverflow.com/questions/13146537/boost-proto-and-complex-transform


Preliminar tests for 1 evaluations of a simple expression `p = q 
+ r * 3.f` where p, q and r are geometric vectors of 3 ints give the 
following promising times:


Regular: 1.15s
Proto: 1.2s
Hand-Unrolled: 0.39s
Proto-Unrolled: 0.8s

Proto expressions build and optimization times are not taken into 
account. There is a considerable number of expression copies made by the 
expression optimization that cannot be avoided by the compiler. I will 
continue my research by implementing a custom evaluation context that 
does this optimization 'on the fly', without actually modifying the 
expression.


Agustín K-ballo Bergé.-
http://fusionfenix.com

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Transform result_of nightmare and preserving terminal identity

[Agustín K-ballo Bergé]

On 16/10/2012 02:22 a.m., Eric Niebler wrote:

Hi Agustín,

This is just a quick note to let you know that I'm currently at the
standard committee meeting in Portland, and that I'll be unable to look
until this until I get back next week.



Thank you for letting me know.

Agustín K-ballo Bergé.-
http://fusionfenix.com

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Transform result_of nightmare and preserving terminal identity

[Eric Niebler]

On 10/13/2012 4:20 PM, Agustín K-ballo Bergé wrote:
 Hi All,
 
 I'm experimenting with Proto to build a DSEL that operates on geometric
 vectors. I'm trying to write a transform that would take an assign
 expression and unroll it component wise. For instance, I want to replace

Hi Agustín,

This is just a quick note to let you know that I'm currently at the
standard committee meeting in Portland, and that I'll be unable to look
until this until I get back next week. Sorry for the delay. Maybe
someone else on this list might be able to help (nudge!). You might also
pose this question on stackoverflow.com.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Joining Proto List

[Fletcher, John P]

Eric suggested that I join this list.

I have been working for some years on FC++ (the old web site died recently 
unfortunately but there is a link to it on 
http://c2.com/cgi/wiki?FunctoidsInCpp ).  I have extended it a lot and also 
worked on a version using concepts to do the return type analysis, so I was sad 
when concepts were dropped from C++11 and hope they come back soon.

I have linked FC++ and Boost Lambda in the past and was working on doing the 
same with Boost Phoenix when it became necessary to learn about Boost Proto as 
well.  So here I am.

I have also been looking at some articles by Bartosz Milewski about the 
implementation of compile time Monads in C++, which seem to be related to 
Proto.  I have had a look around here and not seen anything that obviously 
relates to that.

John Fletcher

Dr John P. Fletcher Tel: (44) 121 204 3389 (direct line), FAX: (44) 121 204 3678
Chemical Engineering and Applied Chemistry (CEAC),
formerly Associate Dean - External Relations,
School of Engineering and Applied Science (EAS),
Aston University, Aston Triangle, BIRMINGHAM B4 7ET  U.K.


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] fold_tree and grammar using external_transforms and state

[Joel Falcou]

Le 27/07/2012 08:11, Eric Niebler a écrit :

You mean, a proto callable that wraps fusion::transform? No, we don't
have one yet. If you write one, I'll put it in proto.


OK


Naming is becoming an issue, though. We already have proto::transform.
You'd be adding proto::functional::transform that would be totally
unrelated. I think I screwed up with the namespaces. It should probably
be proto::functional::fusion::transform. Urg.


Well, I guess this is a breaking change :s

What I need is maybe more generic as I need to apply an arbitrary 
function with arbitrary number of parmaeters, the first beign the 
flattened tree, the others begin whatever:


transform( f, [a b c d], stuff, thingy )
= [f(a,stuff,thingy) f(b,stuff,thingy) f(c,stuff,thingy)]

I'll try and ake it works out of the box first and see how it can be 
generalized.





___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] fold_tree and grammar using external_transforms and state

[Eric Niebler]

On 7/27/2012 12:19 AM, Joel Falcou wrote:
 Le 27/07/2012 08:11, Eric Niebler a écrit :
 Naming is becoming an issue, though. We already have proto::transform.
 You'd be adding proto::functional::transform that would be totally
 unrelated. I think I screwed up with the namespaces. It should probably
 be proto::functional::fusion::transform. Urg.
 
 Well, I guess this is a breaking change :s

I could import the existing stuff into proto::functional for back-compat.

 What I need is maybe more generic as I need to apply an arbitrary
 function with arbitrary number of parmaeters, the first beign the
 flattened tree, the others begin whatever:
 
 transform( f, [a b c d], stuff, thingy )
 = [f(a,stuff,thingy) f(b,stuff,thingy) f(c,stuff,thingy)]

Seems to me you want to be able to bind the 2nd and 3rd arguments to f
so that you can do this with a standard transform.

   transform( [a b c], bind(f, _1, stuff, thingy) )

= [f(a,stuff,thingy) f(b,stuff,thingy) f(c,stuff,thingy)]

 I'll try and ake it works out of the box first and see how it can be
 generalized.

I'll take transform and bind if you write them. :-)

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] fold_tree and grammar using external_transforms and state

[Joel Falcou]

Yeah i figured the code was amiss.
After corrections and using your tip, it works.
The I discovered it was not what I wanted ;)

What I actually need to do is that when I encounter a bunch of
bitwise_and_ node, I need to flatten them then pass this flattened
tree + the initial tuple to the equivalent of fusion transform that will do:

skeleton_grammar(current, current value from state, current 
external_transforms)


I guess proto::functional::transform is not there and need to be done
by hand ?



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] proto-11 progress report

[Eric Niebler]

On 7/17/2012 6:14 PM, Eric Niebler wrote:
 I'm considering adding the slots mechanism to proto-current so that this
 can be made to work there, also. The problem is that once you use a
 slot, the data parameter is no longer just a dumb blob. I can make
 proto::_data ignore the slots and just return the dumb blob as before,
 and that will satisfy some. But any custom primitive transforms that
 folks have written will need to be ready for the fact that they could
 get passed something different than what they were expecting. I don't
 think it will break code until you decide to use a slot (or use a
 transform that uses a slot). Then you'll need to fix up your transforms.
 
 Does anybody object to the above scheme?

This is now implemented on trunk. It's implemented in a backward
compatible way.[*]

What this means is that instead of a monolithic blob of data, the third
parameter to a Proto transforms can be a structured object with O(1)
lookup based on tag. You define a tag with:

  BOOST_PROTO_DEFINE_ENV_VAR(my_tag_type, my_key);

Then, you can use it like this:

  some_transform()(expr, state, (my_key= 42, your_key= hello));

In your transforms, you can access the value associated with a
particular key using the proto::_env_varmy_tag_type transform.

You can still pass an unstructured blob, and things work as they did
before. The proto::_data transform checks to see if the data parameter
is a blob or structured. If it's a blob, that simply gets returned. If
it's structured, it returns the value associated with the
proto::data_type tag. In other words, these two are treated the same:

  int i = 42;
  some_transform()(expr, state, i);
  some_transform()(expr, state, (proto::data= i));

There's more, but I'll save it. It's a big change, and docs are yet to
be written. Y'all might want to test your code against trunk and report
problems early. (This will *not* be part of 1.51.)

[*] I had to make some changes to Phoenix though because unfortunately
Phoenix makes use of some undocumented parts of Proto.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Refining the Proto concepts

[Eric Niebler]

On 7/18/2012 3:59 PM, Mathias Gaunard wrote:
 On 18/07/2012 18:29, Eric Niebler wrote:
 
 Is there some code in Proto that is forcing the instantiation of those
 specializations? Probably, and that would unintended. One approach would
 be to replace these normalized forms with an equivalent incomplete type
 and fix all places where the code breaks.
 
 Doesn't
 
 templateclass T
 struct foo
 {
typedef barT baz;
 };
 
 fooint f = {};
 
 instantiate barT?

No, that merely mentions the specialization barT, but it doesn't
instantiate it. Nothing about that typedef requires barT to be
complete. You can try it yourself. If you make barT incomplete, the
above code still compiles.

Also, matching against the partial specializations of detail::matches_
in matches.hpp also doesn't require the basic_expr specialization to be
complete. But like I said, if there is some sloppy code in there that
requires that nested typedef to be complete, it *will* get instantiated.
Replacing it with an incomplete type will change it from a compile-time
perf bug to a hard error, and those are easy to find and fix.

 The problem I see is that for a regular Proto expression, the whole tree
 gets instantiated twice for expr and basic_expr.

If this is indeed happening, cleaning it up would be a nice perf win.
Want to give it a shot?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Precomputing common matrix products in an expression

[Mathias Gaunard]

On 07/15/2012 10:25 AM, Bart Janssens wrote:


OK, thanks for the comments. It's similar to what I had in mind, but
(unless I'm missing something) all product terms in our expressions
should have a distinct type if they represent different values, so I
could get away with just using a fusion map and avoid the copying and
even the map lookup.


In which case, you can replace the std::mapExpr, result_type by a 
boost::optionalresult_type.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] _unpack transform

[Mathias Gaunard]

On 07/11/2012 06:55 PM, Eric Niebler wrote:


You're referring to this:

http://lists.boost.org/proto/2010/11/0304.php

I should have followed through! The code referenced there isn't
available anymore. I remember putting it on my TODO list to understand
the compile-time implications of it, because of your warning about
compile times. And then ... I don't remember. :-P


It's available here
https://raw.github.com/MetaScale/nt2/169b69d47e4598e403caad0682dd6d24b8fd4668/modules/boost/dispatch/include/boost/dispatch/dsl/proto/unpack.hpp

As I said earlier we got rid of it because it wasn't very practical to 
use, this is from an old revision.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] _unpack transform

[Eric Niebler]

On 7/13/2012 6:37 AM, Mathias Gaunard wrote:
 On 07/11/2012 06:55 PM, Eric Niebler wrote:
 
 You're referring to this:

 http://lists.boost.org/proto/2010/11/0304.php

 I should have followed through! The code referenced there isn't
 available anymore. I remember putting it on my TODO list to understand
 the compile-time implications of it, because of your warning about
 compile times. And then ... I don't remember. :-P
 
 It's available here
 https://raw.github.com/MetaScale/nt2/169b69d47e4598e403caad0682dd6d24b8fd4668/modules/boost/dispatch/include/boost/dispatch/dsl/proto/unpack.hpp

Thanks.

 As I said earlier we got rid of it because it wasn't very practical to
 use, this is from an old revision.

Impractical because of the compile times? Did you replace it with
anything? Would you have any interest in giving the new unpacking
patterns a spin and letting me know if they meet your need, when you
have time?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] _unpack transform

[Eric Niebler]

On 7/11/2012 10:32 AM, Eric Niebler wrote:
   f0(f1(f2(pack(_))...))
 
 That's no so bad, actually. Now, the question is whether I can retrofit
 this into proto-current without impacting compile times.

This is now implemented on boost trunk for proto-current. Seems to work
without a significant perf hit (my subjective sense). Docs forthcoming.
It's also implemented for proto-11. This is a good feature, I think.
Thanks for all the feedback that led to it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] _unpack transform

[Thomas Heller]

On 07/10/2012 11:18 PM, Eric Niebler wrote:

I just committed to the proto-11 codebase a new transform called
_unpack. You use it like this:

   _unpackf0(Tfx, f1(_)...)

Where Tfx represents any transform (primitive or otherwise) f0 is any
callable or object type, and f1(_) is an object or callable transform.
The ... denotes pseudo-pack expansion (although it's really an C-style
vararg ellipsis). The semantics are to replace f1(_)... with
f1(_child0), f1(_child1), etc..

With this, the _default transform is trivially implemented like this:

struct _default
   : proto::or_
 proto::whenproto::terminal_, proto::_value
   , proto::otherwise
 proto::_unpackeval(proto::tag_of_(), _default(_)...)
 
 
{};

...where eval is:

struct eval
{
 templatetypename E0, typename E1
 auto operator()(proto::tag::plus, E0  e0, E1  e1) const
 BOOST_PROTO_AUTO_RETURN(
 static_castE0(e0) + static_castE1(e1)
 )

 templatetypename E0, typename E1
 auto operator()(proto::tag::multiplies, E0  e0, E1  e1) const
 BOOST_PROTO_AUTO_RETURN(
 static_castE0(e0) * static_castE1(e1)
 )

 // Other overloads...
};

The _unpack transform is pretty general, allowing a lot of variation
within the pack expansion pattern. There can be any number of Tfx
transforms, and the wildcard can be arbitrarily nested. So these are all ok:

   // just call f0 with all the children
   _unpackf0(_...)

   // some more transforms first
   _unpackf0(Tfx0, Tfx1, Tfx2, f1(_)...)

   // and nest the wildcard deeply, too
   _unpackf0(Tfx0, Tfx1, Tfx2, f1(f2(f3(_)))...)

I'm still playing around with it, but it seems quite powerful. Thoughts?
Would there be interest in having this for Proto-current? Should I
rename it to _expand, since I'm modelling C++11 pack expansion?

i think _expand would be the proper name. Funny enough i proposed it 
some time ago for proto-current, even had an implementation for it, and 
the NT2 guys are using that exact implementation ;)

Maybe with some extensions.
So yes, Proto-current would benefit from such a transform.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] _unpack transform (was: proto-11 progress report)

[Bart Janssens]

On Tue, Jul 10, 2012 at 11:18 PM, Eric Niebler e...@boostpro.com wrote:
 The _unpack transform is pretty general, allowing a lot of variation
 within the pack expansion pattern. There can be any number of Tfx
 transforms, and the wildcard can be arbitrarily nested. So these are all ok:

   // just call f0 with all the children
   _unpackf0(_...)

Hi Eric,

Is it correct that the above example just generates a sequence of
calls to f0, one for every child of the expression? If so, we are
currently implementing that functionality like this:
https://github.com/coolfluid/coolfluid3/blob/master/cf3/solver/actions/Proto/ExpressionGroup.hpp

So for us this would avoid the (in this case quite simple) primitive transform.

Cheers,

-- 
Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] _unpack transform

[Eric Niebler]

On 7/11/2012 12:42 AM, Thomas Heller wrote:
 On 07/10/2012 11:18 PM, Eric Niebler wrote:
 I just committed to the proto-11 codebase a new transform called
 _unpack. You use it like this:

_unpackf0(Tfx, f1(_)...)

 Where Tfx represents any transform (primitive or otherwise) f0 is any
 callable or object type, and f1(_) is an object or callable transform.
 The ... denotes pseudo-pack expansion (although it's really an C-style
 vararg ellipsis). The semantics are to replace f1(_)... with
 f1(_child0), f1(_child1), etc..

 With this, the _default transform is trivially implemented like this:

 struct _default
: proto::or_
  proto::whenproto::terminal_, proto::_value
, proto::otherwise
  proto::_unpackeval(proto::tag_of_(), _default(_)...)
  
  
 {};

 ...where eval is:

 struct eval
 {
  templatetypename E0, typename E1
  auto operator()(proto::tag::plus, E0  e0, E1  e1) const
  BOOST_PROTO_AUTO_RETURN(
  static_castE0(e0) + static_castE1(e1)
  )

  templatetypename E0, typename E1
  auto operator()(proto::tag::multiplies, E0  e0, E1  e1) const
  BOOST_PROTO_AUTO_RETURN(
  static_castE0(e0) * static_castE1(e1)
  )

  // Other overloads...
 };

 The _unpack transform is pretty general, allowing a lot of variation
 within the pack expansion pattern. There can be any number of Tfx
 transforms, and the wildcard can be arbitrarily nested. So these are
 all ok:

// just call f0 with all the children
_unpackf0(_...)

// some more transforms first
_unpackf0(Tfx0, Tfx1, Tfx2, f1(_)...)

// and nest the wildcard deeply, too
_unpackf0(Tfx0, Tfx1, Tfx2, f1(f2(f3(_)))...)

 I'm still playing around with it, but it seems quite powerful. Thoughts?
 Would there be interest in having this for Proto-current? Should I
 rename it to _expand, since I'm modelling C++11 pack expansion?

 i think _expand would be the proper name. Funny enough i proposed it
 some time ago for proto-current, even had an implementation for it, and
 the NT2 guys are using that exact implementation ;)
 Maybe with some extensions.
 So yes, Proto-current would benefit from such a transform.

You're referring to this:

http://lists.boost.org/proto/2010/11/0304.php

I should have followed through! The code referenced there isn't
available anymore. I remember putting it on my TODO list to understand
the compile-time implications of it, because of your warning about
compile times. And then ... I don't remember. :-P

I remember that it was an invasive change to how Proto evaluates all
transforms, which made me nervous. I also don't think that exact syntax
can be implemented without forcing everybody to pay the compile-time
hit, whether they use the feature or not. In contrast, having a separate
_unpack transform isolates the complexity there.

I'm going to keep playing with this. Your suggested syntax is nice. I
wonder how close I can get. (Although I kinda like my pseudo-pack
expansions, too. :-)

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] _unpack transform (was: proto-11 progress report)

[Eric Niebler]

I just committed to the proto-11 codebase a new transform called
_unpack. You use it like this:

  _unpackf0(Tfx, f1(_)...)

Where Tfx represents any transform (primitive or otherwise) f0 is any
callable or object type, and f1(_) is an object or callable transform.
The ... denotes pseudo-pack expansion (although it's really an C-style
vararg ellipsis). The semantics are to replace f1(_)... with
f1(_child0), f1(_child1), etc..

With this, the _default transform is trivially implemented like this:

struct _default
  : proto::or_
proto::whenproto::terminal_, proto::_value
  , proto::otherwise
proto::_unpackeval(proto::tag_of_(), _default(_)...)


{};

...where eval is:

struct eval
{
templatetypename E0, typename E1
auto operator()(proto::tag::plus, E0  e0, E1  e1) const
BOOST_PROTO_AUTO_RETURN(
static_castE0 (e0) + static_castE1 (e1)
)

templatetypename E0, typename E1
auto operator()(proto::tag::multiplies, E0  e0, E1  e1) const
BOOST_PROTO_AUTO_RETURN(
static_castE0 (e0) * static_castE1 (e1)
)

// Other overloads...
};

The _unpack transform is pretty general, allowing a lot of variation
within the pack expansion pattern. There can be any number of Tfx
transforms, and the wildcard can be arbitrarily nested. So these are all ok:

  // just call f0 with all the children
  _unpackf0(_...)

  // some more transforms first
  _unpackf0(Tfx0, Tfx1, Tfx2, f1(_)...)

  // and nest the wildcard deeply, too
  _unpackf0(Tfx0, Tfx1, Tfx2, f1(f2(f3(_)))...)

I'm still playing around with it, but it seems quite powerful. Thoughts?
Would there be interest in having this for Proto-current? Should I
rename it to _expand, since I'm modelling C++11 pack expansion?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] proto-11 progress report

[Eric Niebler]

On 6/29/2012 4:49 AM, Mathias Gaunard wrote:
 On 28/06/2012 21:09, Eric Niebler wrote:
 
 After meditating on this for a bit, a thought occurred to me. Your
 unpack function is a generalization of the pattern used by the _default
 transform.
 
 It is indeed.

Right. Providing the higher-level primitive transform is on my to-do
list. Thanks for the suggestion.

 Generators are intended to meet this need. What are they lacking for
 you? Is it the lack of an unpack transform?
 
 We use generators for something else. Generators are in charge of
 putting a raw expression in the NT2 domain, which involves computing the
 logical size of the expression as well as the type it would have it
 evaluated.
 
 Doing the expression rewriting in the generator itself causes dependency
 problems, since expression rewriting is defined in terms of unpacking
 then re-making expressions, which involves calling the generator.
 
 I don't know yet how we could do what we need in a generator-less world.

Well, in the present generator world, the generator is passed an
expression, and your mission is to rewrite it (or wrap it). Rewriting
the expression causes a recursive invocation of the generator for the
current expression. This is the cause of the trouble, IIUC.

In the future generator-less world, your domain's make_expr function
object is passed a tag and a bunch of child nodes. You get to decide how
to turn that into an expression. If you want to transform the child
nodes first, you should be able to do that, and it wouldn't recurse
back. You're recursing only on the children, not on the current
expression. That should work. In theory.

 Both optimize and schedule require containing children by value to
 function correctly.

 How is this relevant?
 
 When using normal Proto features, the expressions built from operators
 contain their children by reference while the expression built from
 transforms contain their children by value.
 
 Since in our case we use the same code for both, we had to always
 contain children by value.

I'm afraid I'm being dense. I still don't see how that relates to the
need for your unpack function or the limitations of transforms.

 Transforms are not pure functional. The data parameter can be mutated
 during evaluation.
 
 The transform language is functional since the only thing it does is
 define a calling expression which is a combination of primitive
 transforms. Of course each primitive transform doesn't have to be
 functional, but the language to use them cannot define state, it can
 just pass it along like a monad.

Your unpack function is no less functional in nature. I'm not denying
that transforms have limitations that your unpack function doesn't (see
below). I'm just saying that you're barking up the wrong tree with your
argument about transform's functional nature.

 I guess it's not pure functional though because of proto::and_.

I don't understand this statement.

 In any case, a lot of non-trivial expression evaluation strategies
 cannot be practically implemented as a transform and require a primitive
 transform.

Ah! By transform you mean callable transform or object transform, but
not primitive transform. But the term transform includes primitive
transforms. Is that why we're talking past each other?

 If everything ends up being primitive transforms, we might as well use
 simple function objects directly, which are not tied by constraints such
 as arity, state, data, environment etc., just store whatever state is
 needed in the function object or bind that state with boost::bind or
 similar.

I see what you're getting at. Primitive transforms have limitations on
the number of arguments and the meaning of those arguments. I understand.

 I'd like to see Proto provide algorithms like this that accept arbitrary
 function objects and that are not intended to require transforms to do
 useful things.

Sure. However, I have a reason for wanting to make these things play
nicely with transforms. See below.

 You know about proto::vararg, right? It lets you handle nodes of
 arbitrary arity.
 
 The transformations that can currently be done as a non-primitive
 transform when the transformation must not rely on an explicit arity of
 the expression are extremely limited.

Limiting the discussion to non-primitive transforms, I agree. I didn't
know that's what we were discussing.

 Adding unpacking transforms would certainly make it more powerful, but
 still not as powerful as what you could do with a simple function object
 coupled with macros or variadic templates.
 
 I think it's important to keep in mind that transforms are a possible
 solution that can work well for some languages, but that there should be
 other solutions as well.
 
 Once there is an unpack transform, will you still feel this way?
 
 We already have the unpack algorithm that I described. It's relatively
 simple and straightforward code. We used to have it defined as a
 primitive transform, it was much more complicated 

Re: [proto] proto-11 progress report

[Mathias Gaunard]

On 28/06/2012 21:09, Eric Niebler wrote:


After meditating on this for a bit, a thought occurred to me. Your
unpack function is a generalization of the pattern used by the _default
transform.


It is indeed.



Generators are intended to meet this need. What are they lacking for
you? Is it the lack of an unpack transform?


We use generators for something else. Generators are in charge of 
putting a raw expression in the NT2 domain, which involves computing the 
logical size of the expression as well as the type it would have it 
evaluated.


Doing the expression rewriting in the generator itself causes dependency 
problems, since expression rewriting is defined in terms of unpacking 
then re-making expressions, which involves calling the generator.


I don't know yet how we could do what we need in a generator-less world.



Both optimize and schedule require containing children by value to
function correctly.


How is this relevant?


When using normal Proto features, the expressions built from operators 
contain their children by reference while the expression built from 
transforms contain their children by value.


Since in our case we use the same code for both, we had to always 
contain children by value.




Transforms are not pure functional. The data parameter can be mutated
during evaluation.


The transform language is functional since the only thing it does is 
define a calling expression which is a combination of primitive 
transforms. Of course each primitive transform doesn't have to be 
functional, but the language to use them cannot define state, it can 
just pass it along like a monad.

I guess it's not pure functional though because of proto::and_.

In any case, a lot of non-trivial expression evaluation strategies 
cannot be practically implemented as a transform and require a primitive 
transform.


If everything ends up being primitive transforms, we might as well use 
simple function objects directly, which are not tied by constraints such 
as arity, state, data, environment etc., just store whatever state is 
needed in the function object or bind that state with boost::bind or 
similar.


I'd like to see Proto provide algorithms like this that accept arbitrary 
function objects and that are not intended to require transforms to do 
useful things.




You know about proto::vararg, right? It lets you handle nodes of
arbitrary arity.


The transformations that can currently be done as a non-primitive 
transform when the transformation must not rely on an explicit arity of 
the expression are extremely limited.


Adding unpacking transforms would certainly make it more powerful, but 
still not as powerful as what you could do with a simple function object 
coupled with macros or variadic templates.


I think it's important to keep in mind that transforms are a possible 
solution that can work well for some languages, but that there should be 
other solutions as well.




Once there is an unpack transform, will you still feel this way?


We already have the unpack algorithm that I described. It's relatively 
simple and straightforward code. We used to have it defined as a 
primitive transform, it was much more complicated to use and required 
adding special cases for state and data, and was limited to just that.


I don't see how using a transform that does the same thing but less 
generic would be useful to us.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] proto-11 progress report

[Eric Niebler]

On 6/27/2012 2:11 PM, Mathias Gaunard wrote:
 On 25/06/2012 23:30, Eric Niebler wrote:
 On 6/25/2012 12:21 PM, Mathias Gaunard wrote:
 
 There is a function which is very simple and that I found to be very
 useful when dealing with expression trees.

 unpack(e, f0, f1) which calls
 f0(f1(e.child0), f1(e.child1), ..., f1(e.childN))

 I can do recursion or not with the right f1, and I can 'unpack' an
 expression to an n-ary operation f0.

 Here f0 is typically a function that uses its own overloading-based
 dispatching mechanism.

 OK, thanks for the suggestion. Where have you found this useful?
 
 For example I can use this to call
 
 functortag::plus()(functortag::multiplies()(a, b), c);
 
 from a tree like
 
 exprtag::plus, list2 exprtag::multiplies, list2 exprtag::terminal,
 exprtag::terminal , exprtag:terminal  
 
 NT2 uses a mechanism like this to evaluate expressions.

OK.

 For element-wise expressions (i.e. usual vector operations), the f1 is
 the run(expr, pos) function -- actually more complicated, but there is
 no need to go into details -- which by default simply calls unpack
 recursively.
 
 What the f0 does is simply unpack the expression and call a functor
 associated to the tag (i.e. run(expr, i) with exprtag::pow, list2foo,
 bar  calls pow(run(foo, i), run(bar, i)) ).
 
 The important bit is that it is also possible to overload run for a
 particular node type.
 
 On terminals, the run is defined to do a load/store at the given
 position. This means run(a + b * sqrt(c) / pow(d, e), i)  calls
 plus(a[i], multiplies(b[i], divides(sqrt(c[i]), pow(d[i], e[i]
 
 Each function like plus, multiplies, sqrt, pow, etc. is overloaded so
 that if any of the arguments is an expression, it does a make_expr. If
 the values are scalars, it does the expected operations on scalars. If
 they're SIMD vectors, it does the expected operations on vectors.
 
 run is also overloaded for a variety of operations that depend on the
 position itself, such as restructuring, concatenating or repeating data;
 the position is modified before running the children or different things
 may be run depending on a condition.
 
 A simple example is the evaluation of cat(a, b) where run(expr, i) is
 defined as something a bit like i  size(child0(expr)) ?
 run(child0(expr), i) : run(child1(expr), i-size(child0(expr))
 
 unpack is also used for expression rewriting: before expressions are
 run, the expression is traversed recursively and reconstructed. Whenever
 operations that are not combinable are found, those sub-expressions are
 evaluated and the resulting terminal is inserted in their place in the
 tree. In NT2 this is done by the schedule function.

After meditating on this for a bit, a thought occurred to me. Your
unpack function is a generalization of the pattern used by the _default
transform. The _defaultX transform unpacks an expression, transforms
each child with X, then recombines the result using the C++ meaning
corresponding to the expression's tag type. In other words,
_defaultX()(e) is unpack(e, f0, f1) where f1 is X and f0 is
hard-coded. I could very easily provide unpack as a fundamental
transform and then trivially implement _default in terms of that. I very
much like this idea.

Aside: The pass_through transform almost fits this mold too, except that
each child can get its own f1. Hmm.

Unpack doesn't sound like the right name for it, though. It reminds me a
bit of Haskell's fmap, but instead of always putting the mapped elements
back into a box of the source type, it lets you specify how to box
things on the way out.

 Similarly we have a phase that does the same kind of thing to replace
 certain patterns of combinations by their optimized counterparts
 (optimize). We'd like to do this at construction time but it's currently
 not very practical with the way Proto works.

Generators are intended to meet this need. What are they lacking for
you? Is it the lack of an unpack transform?

 Both optimize and schedule require containing children by value to
 function correctly.

How is this relevant?

 Transforms are not used much since they're only useful for the most
 simple operations due to their pseudo-DSL pure functional nature. It's
 especially problematic when performance sensitive code, which needs to
 be stateful, is involved. 

Transforms are not pure functional. The data parameter can be mutated
during evaluation. Even expressions themselves can be mutated by a
transform, as long as they're non-const.

 Finally it's also not practical to do anything
 involving nodes of arbitrary arity with them.

You know about proto::vararg, right? It lets you handle nodes of
arbitrary arity.

 Unfortunately I cannot say transforms are good enough for the kind of
 thing NT2 does.

Once there is an unpack transform, will you still feel this way?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com


___
proto mailing list
proto@lists.boost.org

Re: [proto] proto-11 progress report

[Joel Falcou]

On 06/24/2012 01:10 AM, Eric Niebler wrote:

I've made some good progress on the C++11 proto rewrite that I'd like to
share. So far, it's been a less radical shift than I expected.


You didn't try hard enough ;)


Expressions vs. Grammars

Many new users are confused by the difference between terminalint and
terminalint::type. In proto.next, there is no difference. Forget the
::type. Things just work.


Neat


Custom transforms are simpler
=
Currently, defining a custom transform means defining a struct with a
nested impl class template of 3 parameters, correctly inheriting and
following a protocol. In the rewrite, I wanted to simplify things. Here
for instance, is how the _expr transform is defined:

 struct _expr
   : transform_expr
 {
 templatetypename E, typename ...Rest
 auto operator()(E  e, Rest ...) const
 BOOST_PROTO_AUTO_RETURN(
 static_castE (e)
 )
 };

A custom transform is simply a struct that inherits from
proto::transform and that has an operator() that accepts an arbitrary
number of parameters. (The use of BOOST_PROTO_AUTO_RETURN is not
necessary. It simply handles the return statement, the return type, and
the noexcept clause.)


Good


Data parameter uses a slot mechanism

In proto today, transforms take 3 parameters: expression, state and
data. As you can see from above, transforms in proto-11 take an
arbitrary number of parameters. However, that can make it hard to find
the piece of data you're looking for. Which position will it be in?
Instead, by convention most transforms will still only deal with the
usual 3 parameters. However, the data parameter is like a fusion::map:
it will have slots that you can access in O(1) by tag.

Here is how a proto algorithm will be invoked:

   int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8);

The 3rd parameter associates the value 8 with the data tag. The _data
transform returns the data associated with that tag. Additionally, you
can define you own tags and pass along another blob of data, as follows:

   int i = LambdaEval()(_1 + 42, 0, (proto::tag::data = 8, mytag = 42));

The _data transform will still just return 8, but you can use
_envmytag_type to fetch the 42. The third parameter has been
generalized from an unstructured blob of data to a structured collection
of environment variables. Slots can even be reused, in which case they
behave like FILO queues (stacks).


How do you set up new tag  ? Is just mytag some

mytag_type mytag = {};

?

or should mytag_type inherit/be wrapped from some special stuff


As for what is not changing:

Grammars, Transforms and Algorithms
===
It would be wonderful if there were a more natural syntax for describing
proto algorithms rather than with structs, function objects, proto::or_,
proto::when, and friends. If there is one, I haven't found it yet. On
the up side, it means that many current proto-based libraries can be
upgraded with little effort. On the down side, the learning curve will
still be pretty steep. If anybody has ideas for how to use C++11 to
simplify pattern matching and the definition of recursive tree
transformation algorithms, I'm all ears.


There is not so much way to describe something that looks like
a grammar definition anyway. BNF/EBNF is probably the simplest
way to do it.

Now on the syntactic clutter front, except wrapping everything in round 
lambda

or use object/function call in a hidden decltype call, I don't see what we
can do better :s


Glad it is picking up steam :D

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] proto-11 progress report

[Eric Niebler]

On 6/25/2012 12:39 AM, Joel Falcou wrote:
 On 06/24/2012 01:10 AM, Eric Niebler wrote:
snip
int i = LambdaEval()(_1 + 42, 0, proto::tag::data = 8);
 
 The 3rd parameter associates the value 8 with the data tag.
snip
 
 How do you set up new tag  ? Is just mytag some
 
 mytag_type mytag = {};
 
 ?
 
 or should mytag_type inherit/be wrapped from some special stuff

Special stuff. Tags are defined as follows:

struct my_tag_type
  : proto::tags::defmy_tag_type
{
using proto::tags::defmy_tag_type::operator=;
};

namespace
{
constexpr my_tag_type const  my_tag =
proto::utility::static_constmy_tag_type::value;
}

The gunk in the unnamed namespace is for strict ODR compliance. A simple
global const would be plenty good for most purposes.

 As for what is not changing:

 Grammars, Transforms and Algorithms
 ===
 It would be wonderful if there were a more natural syntax for describing
 proto algorithms rather than with structs, function objects, proto::or_,
 proto::when, and friends. If there is one, I haven't found it yet. On
 the up side, it means that many current proto-based libraries can be
 upgraded with little effort. On the down side, the learning curve will
 still be pretty steep. If anybody has ideas for how to use C++11 to
 simplify pattern matching and the definition of recursive tree
 transformation algorithms, I'm all ears.
 
 There is not so much way to describe something that looks like
 a grammar definition anyway. BNF/EBNF is probably the simplest
 way to do it.

That would be overkill IMO. Proto grammars don't need to worry about
precedence and associativity. Forcing folks to write E?BNF would mean
forcing them to think about stuff they don't need to think about.

 Now on the syntactic clutter front, except wrapping everything in round
 lambda
 or use object/function call in a hidden decltype call, I don't see what we
 can do better :s

More round lambda, sure. Fixing inconsistencies, also. But I tend to
doubt that using grammar-like expressions in a decltype would be a
significant improvement. Folks still can't write transforms in straight,
idiomatic C++, which is what I want.

 Glad it is picking up steam :D

C++11 has made this pretty fun. I'm ready to stop supporting all my
C++03 libraries now. :-)

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com



signature.asc
Description: OpenPGP digital signature
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] proto-11 progress report

[Mathias Gaunard]

On 24/06/2012 01:10, Eric Niebler wrote:


As for what is not changing:

Grammars, Transforms and Algorithms
===
It would be wonderful if there were a more natural syntax for describing
proto algorithms rather than with structs, function objects, proto::or_,
proto::when, and friends. If there is one, I haven't found it yet. On
the up side, it means that many current proto-based libraries can be
upgraded with little effort. On the down side, the learning curve will
still be pretty steep. If anybody has ideas for how to use C++11 to
simplify pattern matching and the definition of recursive tree
transformation algorithms, I'm all ears.


There is a function which is very simple and that I found to be very 
useful when dealing with expression trees.


unpack(e, f0, f1) which calls
f0(f1(e.child0), f1(e.child1), ..., f1(e.childN))

I can do recursion or not with the right f1, and I can 'unpack' an 
expression to an n-ary operation f0.


Here f0 is typically a function that uses its own overloading-based 
dispatching mechanism.




It needs clang trunk to compile.


Why doesn't it work with GCC?
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

[Dave Abrahams]

on Sat Jun 23 2012, Irit Katriel 
iritkatriel-/E1597aS9LQAvxtiuMwx3w-AT-public.gmane.org wrote:

 Good day, 

 Streamulus is a C++ DSEL for event stream processing. 

 It uses Proto to transform simple expressions into a data structure that 
 computes 
 the expression over an infinite stream of inputs. With user-defined operators 
 that 
 can have side effects or maintain state, this scheme is very flexible. I 
 believe it also
 maps well to the way we (or at least I) tend to think about stream 
 computations. 

 V0.1 is the first 'release', and it consists of the basic functionality, 
 i.e., the language. 
 Future releases will focus on optimisations. 

 See:  

 Project web page:  http://www.streamulus.com 
 Blog: http://streamulus.blogspot.co.uk/(The first post explains the 
 motivation for Streamulus).

 Your feedback will be appreciated. 

Well, I think the hello world example is too simple to illustrate what
this does, and the blog posting is TL;DR, but I skimmed it, and still
didn't really have a clue.  Have you looked at
http://www.boost.org/doc/libs/1_49_0/doc/html/accumulators.html?  It
seems to have some overlap with the problems you're solving.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

[Irit Katriel]

On 24 Jun 2012, at 22:24, Eric Niebler wrote:

 Very interesting! So ... data flow? Or does this take inspiration from
 stream databases?
 


Thank you.

Yes, data flow. With central control to make sure things propagate through the 
graph in topological order.
This is necessary for diamond-shaped graphs (think (x+1)/(x+2)).


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

[Dave Abrahams]

on Sun Jun 24 2012, Eric Niebler 
eric-xT6NqnoQrPdWk0Htik3J/w-AT-public.gmane.org wrote:

 On 6/24/2012 8:50 AM, Irit Katriel wrote:
 
 In the accumulators library, all the accumulators are invoked for
 every update to the input. This is why the visitation order can be
 determined at compile time.

 That's correct.

Are you forgetting about droppable accumulators?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

[Eric Niebler]

On 6/24/2012 4:42 PM, Dave Abrahams wrote:
 
 on Sun Jun 24 2012, Eric Niebler 
 eric-xT6NqnoQrPdWk0Htik3J/w-AT-public.gmane.org wrote:
 
 On 6/24/2012 8:50 AM, Irit Katriel wrote:

 In the accumulators library, all the accumulators are invoked for
 every update to the input. This is why the visitation order can be
 determined at compile time.

 That's correct.
 
 Are you forgetting about droppable accumulators?

Not forgetting. It doesn't change the fact that the visitation order is
set at compile time. There is no centralized, automatic, dynamic flow
control in the accumulators library.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com





signature.asc
Description: OpenPGP digital signature
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Streamulus v0.1 is out: An EDSL for Event Stream Processing with C++

[Irit Katriel]

Good day, 

Streamulus is a C++ DSEL for event stream processing. 

It uses Proto to transform simple expressions into a data structure that 
computes 
the expression over an infinite stream of inputs. With user-defined operators 
that 
can have side effects or maintain state, this scheme is very flexible. I 
believe it also
maps well to the way we (or at least I) tend to think about stream 
computations. 

V0.1 is the first 'release', and it consists of the basic functionality, i.e., 
the language. 
Future releases will focus on optimisations. 

See:  

Project web page:  http://www.streamulus.com 
Blog: http://streamulus.blogspot.co.uk/(The first post explains the 
motivation for Streamulus).

Your feedback will be appreciated. 

Best regards,
Irit



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Joel Falcou]

Just a question that just struck me. Will this rewrite be backward 
compatible with C++03  for the features that make sense ? I think the 
C++03 version may benefit from the new expression extension mechanism etc.


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Who's using proto ?

[Karsten Ahnert]

On 06/06/2012 09:24 PM, Joel Falcou wrote:
 Hi,
 
 i'm in the process of writing a journal paper about proto and I wanted
 to give
 a realistic snapshot of who is using proto and for what. I know some already
 (the whole MSM  Spirit team etc ) but i am sure there is other people
 lurking
 around here.
 
 So, if you want to contribute, I wish any of you, proto user, to tell me
 who you are,
 what you're using proto for and if you have a reference (for academic)
 or a website
 (for other). It's a win-win as you may get exposure and you help us make
 this paper
 a nice PR for proto.
 
 Of course, you can do this on the list or in private if you prefer.
 
 Thanks in advance.
 
 
 ___
 proto mailing list
 proto@lists.boost.org
 http://lists.boost.org/mailman/listinfo.cgi/proto


-- 
Dr. Karsten Ahnert
Ambrosys GmbH - Gesellschaft für Management komplexer Systeme
Geschwister-Scholl-Str. 63a
D-14471 Potsdam

Tel: +4917682001688
Fax: +493319791300

Ambrosys GmbH - Gesellschaft für Management komplexer Systems
Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Geschwister-Scholl-Str. 63a, 14471 Potsdam
Registergericht: Amtsgericht Potsdam, HRB 21228 P
Geschäftsführer: Dr. Karsten Ahnert, Dr. Markus Abel
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Who's using proto ?

[Karsten Ahnert]

On 06/06/2012 09:24 PM, Joel Falcou wrote:
 Hi,
 
 i'm in the process of writing a journal paper about proto and I wanted
 to give
 a realistic snapshot of who is using proto and for what. I know some already
 (the whole MSM  Spirit team etc ) but i am sure there is other people
 lurking
 around here.
 
 So, if you want to contribute, I wish any of you, proto user, to tell me
 who you are,
 what you're using proto for and if you have a reference (for academic)
 or a website
 (for other). It's a win-win as you may get exposure and you help us make
 this paper
 a nice PR for proto.
 
 Of course, you can do this on the list or in private if you prefer.
 
 Thanks in advance.

Hi Joel,

we use proto for the Taylor series method to solve ordinary differential
equations. The method is based on automatic differentiation, and proto
is the tool of choice to do this. The main advantage is that you can
solve ODEs with very high precision within reasonable computation time,
where the classical ODE solvers are relatively slow.

The whole method should be integrated into odeint (odeint.com), which is
a general library for solving ODEs. At the moment we are preparing
odeint for a boost review. We have given some talks about odeint (one at
this years C++Now) and the Taylor series method and there are two small
conference proceedings [1].

Karsten

P.S. sorry for the empty mail.

[1] http://link.aip.org/link/?APCPCS/1389/1586/1 or
http://arxiv.org/abs/1110.3397
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Mathias Gaunard]

On 03/06/2012 09:41, Eric Niebler wrote:


Hey all, this is just an FYI. I've been hard at work at a ground-up
redesign of proto for C++11. I've gotten far enough along that I know
what expression extension will look like, so I thought I'd share. This
should interest those who want finer control over how expressions in
their domain are constructed. Without further ado:

 templatetypename Tag, typename Args
 struct MyExpr;

 struct MyDomain
   : proto::domainMyDomain
 {
 struct make_expr
   : proto::make_custom_exprMyExpr, MyDomain
 {};
 };

 templatetypename Tag, typename Args
 struct MyExpr


Wouldn't it be more interesting for make_custom_expr to take a 
meta-function class?

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Eric Niebler]

On 6/5/2012 11:10 PM, Mathias Gaunard wrote:
 On 03/06/2012 09:41, Eric Niebler wrote:

 Hey all, this is just an FYI. I've been hard at work at a ground-up
 redesign of proto for C++11. I've gotten far enough along that I know
 what expression extension will look like, so I thought I'd share. This
 should interest those who want finer control over how expressions in
 their domain are constructed. Without further ado:

  templatetypename Tag, typename Args
  struct MyExpr;

  struct MyDomain
: proto::domainMyDomain
  {
  struct make_expr
: proto::make_custom_exprMyExpr, MyDomain
  {};
  };

  templatetypename Tag, typename Args
  struct MyExpr
 
 Wouldn't it be more interesting for make_custom_expr to take a
 meta-function class?

The template template parameter is distasteful, I agree, but I can shave
template instantiations this way. There's no need to instantiate a
nested apply template for every new expression type created. Especially
now with template aliases, it's quite painless to adapt a template to
have the interface that make_custom_expr expects. That was my reasoning,
at least.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Mathias Gaunard]

On 06/06/2012 08:24, Eric Niebler wrote:


The template template parameter is distasteful, I agree, but I can shave
template instantiations this way. There's no need to instantiate a
nested apply template for every new expression type created. Especially
now with template aliases, it's quite painless to adapt a template to
have the interface that make_custom_expr expects. That was my reasoning,
at least.


I hadn't considered template aliases, I guess with those it is just fine.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Who's using proto ?

[Joel Falcou]

Hi,

i'm in the process of writing a journal paper about proto and I wanted 
to give

a realistic snapshot of who is using proto and for what. I know some already
(the whole MSM  Spirit team etc ) but i am sure there is other people 
lurking

around here.

So, if you want to contribute, I wish any of you, proto user, to tell me 
who you are,
what you're using proto for and if you have a reference (for academic) 
or a website
(for other). It's a win-win as you may get exposure and you help us make 
this paper

a nice PR for proto.

Of course, you can do this on the list or in private if you prefer.

Thanks in advance.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Hold terminals by smart reference

[Eric Niebler]

On 6/4/2012 5:51 PM, Mathias Gaunard wrote:
 On 04/06/2012 17:52, Eric Niebler wrote:
 
 I don't know what you mean by the right type. If you want it held by
 shared_ptr to manage lifetime, then shared_ptr is the right type, it
 seems to me. Or use a wrapper around a shared_ptr, whichever.
 
 I want all tree manipulation and transformation algorithms to see the
 value as if it were a T and not a shared_ptrT or ref_holderT.

OK, I see.

 shared_ptrT is the right type to contain the terminal in the proto
 nullary expression, but in that particular case it is not the logical
 type of the value associated to that leaf node.
 
 I want to be able to manipulate the tree using straight Proto tools
 (otherwise I might as well not use Proto at all -- the point is to have
 a well-defined de-facto standard framework for tree manipulation).

I understand your frustration.

 Those algorithms should not need to know how the value is stored in the
 expressions. It is just noise as far as they're concerned.
 
 Alternatively I'll need to provide substitutes for value,
 result_of::value and _value, and ban those from my code and the
 programming interface, telling developers to use mybettervalue instead
 of proto's. That saddens me a bit.

I want you to understand that I'm not just being obstructionist or
obstinate. Proto's value functions are very simple and low-level and are
called very frequently. Adding metaprogramming overhead there, as would
be necessary for adding a customization point, has the potential to slow
compiles down for everybody, as well as complicating the code, tests and
docs. There are also unanswered questions. For instance, how does
proto::matches work with these terminals? Does it match on the actual
value or the logical one? There are arguments on both sides, but one
needs to be picked. Going with the logical value will force
proto::matches to go through this customization point for every
terminal. I also am thinking about how it effects other proto features
such as: as_expr, as_child, make_expr, unpack_expr, literal+lit, fusion
integration, display_expr, fold and all the other transforms, etc. etc.
I worry that allowing the logical type of a terminal to differ from the
actual type opens a Pandora's box of tough question with no obvious
answers, and trying to add this would cause unforeseen ripple effects
through the code. It makes me very uneasy, especially considering the
workaround on your end (sorry) is very simple.

Making proto's user's happy must be balanced against feature-creep-ism,
which hurts everybody in the long run. So I'm afraid I'm still leaning
against adding this customization point. But I encourage you to file a
feature request, and if you can find a patch that doesn't negatively
effect compile times or end user-complexity and integrates cleanly with
all the other features of proto and has docs and tests, then -- and only
then --- would I add it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Joel Falcou]

Le 04/06/2012 21:18, Eric Niebler a écrit :

The make_expr function object takes as arguments the tag and the
children. You can do whatever you want. If open extensibility matters,
you can dispatch to a function found by ADL or to a template specialized
on the tag like proto::switch_. It's up to you.


Ok perfect


Not sure what you mean. Are you referring to the current discussion
about having to use shared_ptr to store something? That seems unrelated
to me.

Assuming your types are efficiently movable, the default should just do
the right thing, and your expression trees can be safely stored in local
auto variables without dangling references. Does that help?


I was thinking of the case where we constructed a foo expression by
calling expression constructor one  into the other. I guess it fixes that.


Proto-11 will probably take many months. I'm taking my time and
rethinking everything. Don't hold your work up waiting for it.


No problem, just that if you need some reality check at some point we 
may provide a non trivial test case. We're doing it anyway ;)




___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Eric Niebler]

On 6/4/2012 12:48 PM, Joel Falcou wrote:
 Le 04/06/2012 21:18, Eric Niebler a écrit :
 Assuming your types are efficiently movable, the default should just do
 the right thing, and your expression trees can be safely stored in local
 auto variables without dangling references. Does that help?
 
 I was thinking of the case where we constructed a foo expression by
 calling expression constructor one  into the other. I guess it fixes that.

One into the other? I must be dense. Not getting it. ???

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [proto-11] expression extension

[Eric Niebler]

On 6/4/2012 6:08 PM, Mathias Gaunard wrote:
 Eric Niebler wrote:
 Proto-11 will probably take many months. I'm taking my time and
 rethinking everything. Don't hold your work up waiting for it.
 
 Best thing to do is probably to make it lighter, keep separate things
 separate, and truly extendable.
 
 For example, transforms seem too tighly coupled with the rest in the
 current Proto version, and their limitations are quite intrusive.

Can you be more specific and give some examples? BTW, I appreciate your
helping to improve proto.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] restructuring expression

[Karsten Ahnert]

I have an arithmetic expression template where multiplication is
commutative. Is there an easy way to order a chain of multiplications
such that terminals with values (like proto::terminal double ) appear
at the beginning? For example that

arg1 * arg1 * 1.5 * arg1

will be transformed to

1.5 * arg1 * arg1 * arg1

?

I can imagine some complicated algorithms swapping expressions and child
expressions but I wonder if there is a simpler way.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] restructuring expression

[Eric Niebler]

On 5/29/2012 1:44 AM, Karsten Ahnert wrote:
 I have an arithmetic expression template where multiplication is
 commutative. Is there an easy way to order a chain of multiplications
 such that terminals with values (like proto::terminal double ) appear
 at the beginning? For example that
 
 arg1 * arg1 * 1.5 * arg1
 
 will be transformed to
 
 1.5 * arg1 * arg1 * arg1
 
 ?
 
 I can imagine some complicated algorithms swapping expressions and child
 expressions but I wonder if there is a simpler way.

There is no clever built-in Proto algorithm for commutative
transformations like this, I'm afraid. I was going to suggest flattening
to a fusion vector and using fusion sort, but I see there is no fusion
sort! :-( Nevertheless, that seems like a promising direction to me.
Once you have the sorted vector, you should(?) be able to use
fusion::fold to build the correct proto tree from it.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Feature request: control how the built-in operator overloads build expressions

[Mathias Gaunard]

On 11/05/2012 20:34, Eric Niebler wrote:


This seems quite reasonable. Could you file a feature request on trac so
I don't loose track of it? Thanks.


Trac ticket #6891
https://svn.boost.org/trac/boost/ticket/6891

I wanted to discuss this first because I was afraid you might discard 
the idea outright and say it's the job of the generator to deal with this.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Feature request: control how the built-in operator overloads build expressions

[Mathias Gaunard]

Proto comes with operator overloads that call make_expr if the arguments 
are in a compatible domain and if the grammar is satisfied.


In some cases however, we'd like to build custom trees that don't 
exactly map to what the default operator overloads would do. We suggest 
adding an extension point per-domain to specify how to make_expr but 
only in the context of the provided operator overloads.


The transformation could arguably be done in the generator or in a later 
pass, but we'd prefer doing that early for different reasons:
 - This only affects expressions generated through the built-in 
operator overloads. Other expressions are generated through our custom 
functions, which already do what we want.
 - We'd like to keep the responsibility of the generator of converting 
a naked expression to an expression in our domain (which, in the case of 
NT2, involves computing the size and logical type of the elements).
 - Doing it at a later pass means we have to run the generator on 
things that don't necessarily have the desired form


The alternative is for us to not rely on Proto-defined operator 
overloads and to overload all that stuff ourselves.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Restructuring noses in generator

[Joel Falcou]

On 04/29/2012 02:41 AM, Eric Niebler wrote:
And some_terminal is not in your domain? How does your generator get 
invoked? I guess I'm confused. Can you send a small repro? 


everything is in my domain, no problem ont his side, I'll try Mathias 
idea and report if anything breaks.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Restructuring noses in generator

[Mathias Gaunard]

On 27/04/12 21:47, Joel Falcou wrote:

How can I use a custom generator to turn a specific node expression into
a different version of itself without triggering endless recursive call ?

My use cas is the following, i want to catch all function node looking
like

tag::function( some_terminal, grammar, ..., grammar )

with any nbr of grammar instances

into

tag::function( some_terminal, my_tuple_terminalgrammar, ..., grammar,
some_other_info )

basically makign n-ary function node into ternayr node with a specific
structures. Of course this new node should live in whatever domain
some_terminal is coming from.

My first attempt was using make_expr in my generator but it endlessly
looped at compile time.

Is there somethign I am missing ?


You could just make make_expr use the default_domain to avoid the recursion.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Restructuring noses in generator

[Eric Niebler]

On 4/28/2012 3:38 AM, Mathias Gaunard wrote:
 On 27/04/12 21:47, Joel Falcou wrote:
 How can I use a custom generator to turn a specific node expression into
 a different version of itself without triggering endless recursive call ?

 My use cas is the following, i want to catch all function node looking
 like

 tag::function( some_terminal, grammar, ..., grammar )

 with any nbr of grammar instances

 into

 tag::function( some_terminal, my_tuple_terminalgrammar, ..., grammar,
 some_other_info )

 basically makign n-ary function node into ternayr node with a specific
 structures. Of course this new node should live in whatever domain
 some_terminal is coming from.
snip

And some_terminal is not in your domain? How does your generator get
invoked? I guess I'm confused. Can you send a small repro?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] The proper way to compose function returning expressions

[Eric Niebler]

On 4/25/2012 1:41 PM, Mathias Gaunard wrote:
 On 24/04/12 22:31, Eric Niebler wrote:
 On 4/23/2012 10:17 PM, Joel Falcou wrote:
 On 04/24/2012 12:15 AM, Eric Niebler wrote:

 I think this is an important issues to solve as far as Proto grokability
 does.

 Agreed. It would be very nice to have. But you still have to know when
 to use it.

 One of my coworker on NT2 tried  to do just this (the norm2 thingy) and
 he get puzzled by the random crash.

 [...]

 The implicit_expr code lived in a detail namespace in past versions of
 proto. You can find it if you dig through subversion history. I'm not
 going to do that work for you because the code was broken in subtle ways
 having to do with the consistency of terminal handling. Repeated
 attempts to close the holes just opened new ones. It really should be
 left for dead. I'd rather see what you come up with on your own.
 
 The issue Joel had in NT2 was probably unrelated to this. In NT2 we hold
 all expressions by value unless the tag is boost::proto::tag::terminal.
 This was done by modifying as_child in our domain.
 
 I strongly recommend doing this for most proto-based DSLs. It makes auto
 foo = some_proto_expression work as expected, and allows expression
 rewriting of the style that was shown in the thread without any problem.
 
 There is probably a slight compile-time cost associated to it, though.

Interesting. I avoided this design because I was uncertain whether the
compiler would be able to optimize out all the copies of the
intermediate nodes. You're saying NT2 does it this way and doesn't
suffer performance problems? And you've hand-checked the generated code
and found it to be optimal? That would certainly change things.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] The proper way to compose function returning expressions

[Mathias Gaunard]

On 26/04/12 18:02, Eric Niebler wrote:


Interesting. I avoided this design because I was uncertain whether the
compiler would be able to optimize out all the copies of the
intermediate nodes. You're saying NT2 does it this way and doesn't
suffer performance problems? And you've hand-checked the generated code
and found it to be optimal? That would certainly change things.



NT2 treats large amounts of data per expression, so construction time is 
not very important. It's the time to evaluate the tree in a given 
position that matters (which only really depends on proto::value and 
proto::child_cN, which are always inlined now).


We also have another domain that does register-level computation, where 
construction overhead could be a problem. The last tests we did with 
this was a while ago and was with the default Proto behaviour. That 
particular domain didn't get sufficient testing to give real conclusions 
about the Proto overhead.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] The proper way to compose function returning expressions

[Eric Niebler]

On 4/26/2012 9:35 AM, Mathias Gaunard wrote:
 On 26/04/12 18:02, Eric Niebler wrote:
 
 Interesting. I avoided this design because I was uncertain whether the
 compiler would be able to optimize out all the copies of the
 intermediate nodes. You're saying NT2 does it this way and doesn't
 suffer performance problems? And you've hand-checked the generated code
 and found it to be optimal? That would certainly change things.

 
 NT2 treats large amounts of data per expression, so construction time is
 not very important. It's the time to evaluate the tree in a given
 position that matters (which only really depends on proto::value and
 proto::child_cN, which are always inlined now).
 
 We also have another domain that does register-level computation, where
 construction overhead could be a problem. The last tests we did with
 this was a while ago and was with the default Proto behaviour. That
 particular domain didn't get sufficient testing to give real conclusions
 about the Proto overhead.

In that case, I will hold off making any core changes to Proto until I
have some evidence that it won't cause performance regressions.

Thanks,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] The proper way to compose function returning expressions

[Eric Niebler]

On 4/23/2012 10:17 PM, Joel Falcou wrote:
 On 04/24/2012 12:15 AM, Eric Niebler wrote:
 implicit_expr() returns an object that holds its argument and is
 convertible to any expression type. The conversion is implemented by
 trying to implicitly convert all the child expressions, recursively.
 It sort of worked, but I never worked out all the corner cases, and
 documenting it would have been a bitch. Perhaps I should take another
 look. Patches welcome. :-) 
 
 I think this is an important issues to solve as far as Proto grokability
 does.

Agreed. It would be very nice to have. But you still have to know when
to use it.

 One of my coworker on NT2 tried  to do just this (the norm2 thingy) and
 he get puzzled by the random crash.
 
 I think we should at least document the issues (I can write that and
 submit a patch for the doc) and
 maybe resurrect this implicit_expr. Do you have any remnant of code
 lying around so I don't start from scratch ?

The implicit_expr code lived in a detail namespace in past versions of
proto. You can find it if you dig through subversion history. I'm not
going to do that work for you because the code was broken in subtle ways
having to do with the consistency of terminal handling. Repeated
attempts to close the holes just opened new ones. It really should be
left for dead. I'd rather see what you come up with on your own.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] The proper way to compose function returning expressions

[Joel Falcou]

Let's say we have a bunch of functions like sum and sqr defined on a 
proto domain to return
expression of tag sum_ and sqr_ in this domain. One day we want to make 
a norm2(x) function

which is basically sum(sqr(x)).

My feeling is that I should be able to write it using sqr and sum 
expressions.

Alas it seems this results in dandling reference, crash and some sad pandas.

Then I remember about proto::deep_copy but I have a worries. x is 
usually a terminal
holding a huge matrix like value and I just don't want this huge matrix 
to be copied.


What's the correct way to handle such a problem ? How can I build new 
function returning
expressions built from expression composition without incurring a huge 
amount of copy ?



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] The proper way to compose function returning expressions

[Eric Niebler]

On 4/23/2012 1:01 PM, Joel Falcou wrote:
 Let's say we have a bunch of functions like sum and sqr defined on a
 proto domain to return
 expression of tag sum_ and sqr_ in this domain. One day we want to make
 a norm2(x) function
 which is basically sum(sqr(x)).
 
 My feeling is that I should be able to write it using sqr and sum
 expressions.
 Alas it seems this results in dandling reference, crash and some sad pandas.
 
 Then I remember about proto::deep_copy but I have a worries. x is
 usually a terminal
 holding a huge matrix like value and I just don't want this huge matrix
 to be copied.
 
 What's the correct way to handle such a problem ? How can I build new
 function returning
 expressions built from expression composition without incurring a huge
 amount of copy ?

Right. The canonical way of doing this is as follows:

#include boost/proto/proto.hpp
namespace proto = boost::proto;

struct sum_ {};
struct sqr_ {};

namespace result_of
{
templatetypename T
struct sum
  : proto::result_of::make_exprsum_, T
{};

templatetypename T
struct sqr
  : proto::result_of::make_exprsqr_, T
{};

templatetypename T
struct norm2
  : sumtypename sqrT::type
{};
}

templatetypename T
typename result_of::sumT ::type const
sum(T t)
{
return proto::make_exprsum_(boost::ref(t));
}

templatetypename T
typename result_of::sqrT ::type const
sqr(T t)
{
return proto::make_exprsqr_(boost::ref(t));
}

templatetypename T
typename result_of::norm2T ::type const
norm2(T t)
{
return
proto::make_exprsum_(proto::make_exprsqr_(boost::ref(t)));
}

int main()
{
sum(proto::lit(1));
sqr(proto::lit(1));
norm2(proto::lit(1));
}


As you can see, the norm2 is not implemented in terms of the sum and sqr
functions. That's not really ideal, but it's the only way I know of to
get fine grained control over which parts are stored by reference and
which by value.

You always need to use make_expr to build expression trees that you
intend to return from a function. That's true even for the built-in
operators. You can't ever return the result of expressions like a+b*42
... because of the lifetime issues.

You can't use deep_copy for the reason you mentioned.

I once had a function proto::implicit_expr, which you could have used
like this:

templatetypename T
typename result_of::norm2T ::type const
norm2(T t)
{
return proto::implicit_expr(sum(sqr(x)));
}

implicit_expr() returns an object that holds its argument and is
convertible to any expression type. The conversion is implemented by
trying to implicitly convert all the child expressions, recursively. It
sort of worked, but I never worked out all the corner cases, and
documenting it would have been a bitch. Perhaps I should take another
look. Patches welcome. :-)

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] The proper way to compose function returning expressions

[Joel Falcou]

On 04/24/2012 12:15 AM, Eric Niebler wrote:
implicit_expr() returns an object that holds its argument and is 
convertible to any expression type. The conversion is implemented by 
trying to implicitly convert all the child expressions, recursively. 
It sort of worked, but I never worked out all the corner cases, and 
documenting it would have been a bitch. Perhaps I should take another 
look. Patches welcome. :-) 


I think this is an important issues to solve as far as Proto grokability 
does.
One of my coworker on NT2 tried  to do just this (the norm2 thingy) and 
he get puzzled by the random crash.


I think we should at least document the issues (I can write that and 
submit a patch for the doc) and
maybe resurrect this implicit_expr. Do you have any remnant of code 
lying around so I don't start from scratch ?


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Held nodes by value for Fundamental types

[Joel Falcou]

On 10/04/2012 00:00, Eric Niebler wrote:

Thanks. I thought long about whether to handle the fundamental types
differently than user-defined types and decided against it. The
capture-everything-by-reference-by-default model is easy to explain and
reason about. Special cases can be handled on a per-domain basis as needed.


By-value capture of fundamental type is the classical way people do it 
in hand-made ET code. The ad-hoc support in proto is IMHO better as you 
may really want to capture reference and by the status of Proto of a 
EDSL toolkit, flexibility is really wanted :).


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Held nodes by value for Fundamental types

[Fernando Pelliccioni]

On Tue, Apr 10, 2012 at 3:12 AM, Joel Falcou joel.fal...@lri.fr wrote:

 On 10/04/2012 00:00, Eric Niebler wrote:

 Thanks. I thought long about whether to handle the fundamental types
 differently than user-defined types and decided against it. The
 capture-everything-by-**reference-by-default model is easy to explain and
 reason about. Special cases can be handled on a per-domain basis as
 needed.


 By-value capture of fundamental type is the classical way people do it in
 hand-made ET code. The ad-hoc support in proto is IMHO better as you may
 really want to capture reference and by the status of Proto of a EDSL
 toolkit, flexibility is really wanted :).


Right. I agree with your opinion.

Maybe by defining another domain like default_domain_fundamental_by_value
(please don't use that name :-)).
Thus, the user saves typing as_child if all she/he is looking for is to
change this behavior.

Regards,
Fernando.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Held nodes by value for Fundamental types

[Fernando Pelliccioni]

Hello,

I'm wondering if it would be appropriate to treat the fundamental types
(char, short, int, double, ...) by value, by default.

I wrote this simple piece of code.
I'm not sure if I'm leaving without considering any other implication, but
I think it may be an improvement.
Please, tell me if I am wrong.

Thanks and regards,
Fernando Pelliccioni.


//BEGIN CODE
**
#include boost/proto/proto.hpp

namespace math
{

template typename T
struct dynamic_matrix
{
  dynamic_matrix(std::size_t x_lenght, std::size_t y_lenght)
  {
//...
  }
  //Expensive Copy Constructor!!
  //...
};

}  // namespace math



using namespace boost;

//-

#define BOOST_PROTO_DEFINE_BINARY_OPERATOR_PRIMITIVE(OP, TAG, TRAIT,
DOMAIN, PRIMITIVE)\
  templatetypename Left
   \
  BOOST_FORCEINLINE
   \
  typename boost::proto::detail::enable_binary
   \
  DOMAIN
\
  , DOMAIN::proto_grammar
   \
  , BOOST_PROTO_APPLY_BINARY_(TRAIT, Left, PRIMITIVE)
   \
  , TAG
   \
  , Left const 
\
  , PRIMITIVE
   \
  ::type const
   \
  operator OP(Left left, PRIMITIVE right)
   \
  {
   \
  return boost::proto::detail::make_expr_TAG, DOMAIN, Left const ,
PRIMITIVE()(left, right);\
  }
   \
  templatetypename Right
\
  BOOST_FORCEINLINE
   \
  typename boost::proto::detail::enable_binary
   \
  DOMAIN
\
  , DOMAIN::proto_grammar
   \
  , BOOST_PROTO_APPLY_BINARY_(TRAIT, PRIMITIVE, Right)
\
  , TAG
   \
  , PRIMITIVE
   \
  , Right const 
   \
  ::type const
   \
  operator OP(PRIMITIVE left, Right right)
\
  {
   \
  return boost::proto::detail::make_expr_TAG, DOMAIN, PRIMITIVE, Right
const ()(left, right);   \
  }
  /**/

//-

namespace math
{
  template typename T
  struct is_terminal
: mpl::false_
  {};

  template typename U
  struct is_terminaldynamic_matrixU 
: mpl::true_
  {};

  BOOST_PROTO_DEFINE_OPERATORS(is_terminal, proto::default_domain)
  BOOST_PROTO_DEFINE_BINARY_OPERATOR_PRIMITIVE(*,
boost::proto::tag::multiplies, is_terminal, proto::default_domain, int)

} //namespace math


int main( /* int argc, char* argv[] */ )
{
  using math::dynamic_matrix;
  dynamic_matrixint m1(5, 5);   //define the x and y size of the
matrix
  dynamic_matrixint m2(5, 5);

  auto e = m1 + m2;   // m1 and m2 are held by reference
  auto e2 = m1 * m2;  // m1 and m2 are held by reference
  auto e3 = m1 * 5;   // m1 is held by reference. 5 is
held by value - NO dangling references
  auto e4 = proto::deep_copy(m1 * m2);// Expensive copy of m1 and m2
  auto e5 = proto::deep_copy(m1 * 5); // Expensive copy of m1
  auto e6 = m1 + m2 * 5;  // m1 and m2 are held by
reference. 5 is held by value - NO dangling references
  auto e7 = m1 + m2 + dynamic_matrixint(5, 5); //dangling reference - I
don't care - Needed deep_copy

  return 0;
}

//END CODE
**
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Held nodes by value for Fundamental types

[Eric Niebler]

On 4/9/2012 2:21 PM, Fernando Pelliccioni wrote:
 Hello,
 
 I'm wondering if it would be appropriate to treat the fundamental types
 (char, short, int, double, ...) by value, by default.
 
 I wrote this simple piece of code.
 I'm not sure if I'm leaving without considering any other implication,
 but I think it may be an improvement.
 Please, tell me if I am wrong.

Thanks. I thought long about whether to handle the fundamental types
differently than user-defined types and decided against it. The
capture-everything-by-reference-by-default model is easy to explain and
reason about. Special cases can be handled on a per-domain basis as needed.

There is a way to change the capture behavior for your domain. The newly
released version of Proto documents how to do this (although the
functionality has been there for a few releases already).

http://www.boost.org/doc/libs/1_49_0/doc/html/proto/users_guide.html#boost_proto.users_guide.front_end.customizing_expressions_in_your_domain.per_domain_as_child

In short, you'll need to define an as_child metafunction in your domain
definition:

class my_domain
  : proto::domain my_generator, my_grammar 
{
// Here is where you define how Proto should handle
// sub-expressions that are about to be glommed into
// a larger expression.
template typename T 
struct as_child
{
typedef unspecified-Proto-expr-type result_type;

result_type operator()( T  t ) const
{
return unspecified-Proto-expr-object;
}
};
};

In as_child, you'll have to do this (pseudocode):

if (is_exprT)
  return T 
else if(is_fundamentalT)
  return proto::terminalT::type
else
  return proto::terminalT ::type

The metaprogramming is left as an exercise. :-)

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Best way to change tag in generator?

[Mathias Gaunard]

On 01/31/2012 07:01 PM, Eric Niebler wrote:


You mean, for instance, you want Proto's operator+ to return an
expression with a tag other than tag::plus?


Yes.



Can I ask why?


I need to attach certain information to the type of operation that the 
tag represents, and putting that information as typedefs in the tag type 
itself would be fairly convenient.


Most of my tags are user-defined, except from the ones that map to 
built-in C++ operators.


Of course, I could also just have a mapping of proto tags to custom tags 
that have that information (that is what I'm currently doing).


I was just being curious whether another approach was possible.



You can do
this in a generator, but you're right to be cautious of compile times.
Proto will instantiate a bunch of templates while assembling each
expression before passing them to your generator, which would just rip
them apart and throw them away.

Your other option would be to use the (undocumented)
BOOST_PROTO_DEFINE_UNARY_OPERATOR and
BOOST_PROTO_DEFINE_BINARY_OPERATOR to define a complete alternate set
of operator overloads that use your tags instead of proto's. See
proto/operators.hpp. Nobody has ever done this and I don't know if it
would work.


I guess I won't take that option then ;)
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] user docs for advanced features

[Fernando Pelliccioni]

Hi Eric,

On Mon, Jan 2, 2012 at 9:55 PM, Eric Niebler e...@boostpro.com wrote:

 Proto's users guide has been behind the times for a while. No longer.
 More recent and powerful features are now documented. Feedback welcome.

 Sub-domains:
 

 http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/front_end/customizing_expressions_in_your_domain/subdomains.html


Is this sentence correct?

In light of the above discussion about sub-domains, one could think of
proto::default_domain as a sub-domain of *every other domain*.

^^

I think it should be:

In light of the above discussion about sub-domains, one could think of
proto::default_domain as a super-domain of *every other domain*.


Regards,
Fernando.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] user docs for advanced features

[Eric Niebler]

On 1/4/2012 7:37 AM, Thomas Heller wrote:
snip many good suggestions
 Thanks for adding this documentation!

Great feedback. I've just accommodated all of it. Thanks!

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Grouping expressions

[Joel Falcou]

On 30/12/2011 17:34, Bart Janssens wrote:


On Fri, Dec 30, 2011 at 7:01 AM, Eric 
Nieblereric-xT6NqnoQrPdWk0Htik3J/w...@public.gmane.org  wrote:

Are you certain your problem is caused by using operator() for grouping?
I think this is just a very big expression template, and any syntax you
choose for grouping will result in long compile times and heavy memory
usage.


Yes, that's what I mean, the way grouping works now always creates a
huge expression.


You cant really do anything else. ET captures the whole AST and this AST 
has to be stored somehow.



Can I ask, what version of Boost are you using? I see you #define
BOOST_PROTO_MAX_ARITY to 10 at the top. In recent versions of Proto, 10
is the default. And newer Proto versions already make use of variadic
templates for operator() if available.


I'm using 1.46.1 for now. Good to hear variadic templates are already
available for this, do I need to do anything explicit to enable them,
such as add a compile option?



Compiles in C++11 mode : --std=c++0x


Other things to think about: does this really need to be all one big
expression, or can parts of it be broken up and type-erased, as with
spirit::qi::rule?


Not sure how this type-erased method works, but all of the expressions
are ran in a tight loop, so I'd like to avoid the overhead of having
to go through a virtual call. Also, I use some introspection across
the whole expression to determine which variables exist.


type erasure allow your template class to inherit from a single, 
non-template base class that forward its evaluation to its actual

derived class via a single virtual member function entry-point.

At some point, you need to do this or your CT just explode. And for your
performance matter, I think it need to be benched, type erased calls 
usually are no more than some cycles slower to call.


On the front of introspection, we found out in NT2 that performing some
introspecting tasks in the expression generator (when it made sense) 
helped keep the CT madness low as the resulting AST can be trimmed as 
soon as it is built. Not sure if it applies here.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] user docs for advanced features

[Eric Niebler]

Proto's users guide has been behind the times for a while. No longer.
More recent and powerful features are now documented. Feedback welcome.

Sub-domains:

http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/front_end/customizing_expressions_in_your_domain/subdomains.html

Per-domain as_child customization:
==
http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/front_end/customizing_expressions_in_your_domain/per_domain_as_child.html

External Transforms:
===
http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/back_end/expression_transformation/external_transforms.html

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Problems with unary function node

[Eric Niebler]

On 10/22/2011 3:02 PM, Mathias Gaunard wrote:
 On 10/18/2011 05:53 AM, Eric Niebler wrote:
 On 10/12/2011 2:24 PM, Mathias Gaunard wrote:
 There seems to be a significant problem with the unary function node
 (and by that I mean (*this)() ) generated by proto::extends and
 BOOST_PROTO_EXTENDS_USING_FUNCTION().
 snip

 Sorry for the delay, and I'm afraid I don't have news except to say that
 this is on my radar. I hope to look into this soon. But if someone were
 to beat me to it, that'd be pretty awesome. :-)
 
 I don't think it can really be fixed in C++03.
 In C++11 though, it's pretty easy, you can just make it a template with
 a default template argument.

It should already be fixed for C++11 because operator() uses variadics
if they're available. It's been that way for a while. But in
investigating this problem, I've found that the copy assign operator can
cause the same problem, and that can't be fixed this way, even in C++11.

Regardless, I'm convinced that a complete fix is possible, and I have it
mostly coded. It would require you (the user) to disable unary function
and assign in your domain via a grammar. But. It's expensive at compile
time, and everybody pays. I need to be convinced before I proceed. Your
example code was very contrived. (Certainly you don't need to ask a
Proto expression extension type whether it is a proto expression. The
answer will always be yes.) So what is your realistic usage scenario?
What type categorization do you want to do on the extension type that
you can't do on the raw passed-in expression?

Thanks,

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Problems with unary function node

[Mathias Gaunard]

On 10/18/2011 05:53 AM, Eric Niebler wrote:

On 10/12/2011 2:24 PM, Mathias Gaunard wrote:

There seems to be a significant problem with the unary function node
(and by that I mean (*this)() ) generated by proto::extends and
BOOST_PROTO_EXTENDS_USING_FUNCTION().

snip

Sorry for the delay, and I'm afraid I don't have news except to say that
this is on my radar. I hope to look into this soon. But if someone were
to beat me to it, that'd be pretty awesome. :-)



I don't think it can really be fixed in C++03.
In C++11 though, it's pretty easy, you can just make it a template with 
a default template argument.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Defining the result domain of a proto operator

[Joel Falcou]

On 26/08/2011 17:18, Eric Niebler wrote:

Why can't you use a grammar to recognize patterns like these and take
appropriate action?


we do. Another point is that container based operation in our system 
need to know the number of dimension of the container. Domains carry 
this dimensions informations as we dont want to mix different sized 
container in a same expression. The containers we have are :


table which can have 1 to MAX_DIM dimesnions
matrix which behave as table2 when mixed with table
covector and vector that act as a matrix when mixed with matrix adn 
table2 with table.


The domain are then flagged with this dimension informations.


___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [Proto] Expression as fusion/MPL sequence

[Eric Niebler]

On 6/2/2011 11:12 AM, Joel falcou wrote:
 On 01/06/11 22:24, Eric Niebler wrote:
 
 Proto expressions are random access, but flattened views are
 forward-only. That's a limitation of the current implementation of the
 segmented Fusion stuff. It's a known problem. Segmented fusion needs a
 complete rewrite, but it's a metaprogramming Everest, and I'm too tired
 to climb it again. Some hot-shot metaprogramming wunderkind should try
 cutting his/her teeth on that problem. They'd earn my eternal admiration
 and appreciation.
 
 Oh OK. So i may just need to *not* flatten them.

I just updated the docs to state that flatten returns a Fusion Forward
Sequence.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] [Proto] Expression as fusion/MPL sequence

[Eric Niebler]

On 6/2/2011 7:02 AM, Joel Falcou wrote:
 Seems somethign crooky on this front. Calling fusion::at_c on expression
 ends up in error even after including boost/proto/fusion.hpp.
 Same way, flatten used as a transform seems to not give me a type that
 can be passed to any fusion or mpl function. Looking at
 proto/fusion.hpp I noticed that the iterator is indeed random_access but
 not the view itself which as a forward_traversal tag. Even
 after fixing this, no dice, at_cN(some_proto_expr) still fails to
 compile.

That's odd. Proto's fusion tests are passing on trunk and release, and
the following program compiles for me (on trunk):

  #include boost/proto/proto.hpp
  #include boost/fusion/include/at_c.hpp

  namespace proto = boost::proto;
  namespace fusion = boost::fusion;

  int main()
  {
proto::terminalint::type i = {42};
fusion::at_c1(i + i);
  }

Can you post some code that demonstrates the problem?

Proto expressions are random access, but flattened views are
forward-only. That's a limitation of the current implementation of the
segmented Fusion stuff. It's a known problem. Segmented fusion needs a
complete rewrite, but it's a metaprogramming Everest, and I'm too tired
to climb it again. Some hot-shot metaprogramming wunderkind should try
cutting his/her teeth on that problem. They'd earn my eternal admiration
and appreciation.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] proto::expr vs. proto::basic_expr

[Thomas Heller]

Hi,

Today I experimented a little bit with phoenix and proto.
My goal was to decrease the compile time of phoenix. When I started the 
development of phoenix, Eric advised me to use proto::basic_expr to reduce 
compile times.
Which makes sense giving the argumentation that on instatiating the expression 
node, basic_expr has a lot less functions etc. thus the compiler needs to 
instantiate less. So much for the theory.
In practice this, sadly is not the case. Today I made sure that phoenix uses 
basic_expr exclusively (did not commit the changes).

The result of this adventure was that compile times stayed the same. I was a 
little bit disappointed by this result.

Does anybody have an explanation for this?

Regards,
Thomas
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Compiling in debug mode

[Daniel Oberhoff]

Am Freitag, den 13.05.2011, 09:59 +0700 schrieb Eric Niebler:
 On 5/13/2011 5:45 AM, Bart Janssens wrote:
  Hi guys,

[..]

  Is anyone aware of
  tweaks for GCC that reduce memory usage, but still produce useful
  debug info (just using -g now, no optimization)?
 
 I'll leave this for the gcc experts.
 
  I've gotten to the point where a compile can use upwards of 1.5GB for
  a single test, resulting in much swapping, especially when compiling
  with make -j2 (which I try to remember not to do, now ;).
 
 Ouch. Do you have to use gcc? Perhaps clang might give you better results.
 

Maybe, but if you want to keep on using gcc, you can pass it some extra
options that influence its internal memory manager (there is a garbage
collector inside gcc...). These work for me:

--param ggc-min-expand=30 --param ggc-min-heapsize=8192

in effect I think it is a space/speed tradeoff, though I haven't noticed
any major slowdown.

Best

Daniel

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

Re: [proto] Compiling in debug mode

[Bart Janssens]

On Fri, May 13, 2011 at 9:46 AM, Daniel Oberhoff
daniel.oberh...@fit.fraunhofer.de wrote:
 --param ggc-min-expand=30 --param ggc-min-heapsize=8192

 in effect I think it is a space/speed tradeoff, though I haven't noticed
 any major slowdown.

Thanks, these do reduce memory (somewhat), though there is a large
slowdown in my case. I'll look into upgrading to the latest proto, and
try with clang as well.

I've also googled a bit more about the problem, and found this
interesting blog post:
http://cpptruths.blogspot.com/2010/03/faster-meta-programs-using-gcc-45-and.html

Cheers,

-- 
Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto

[proto] Compiling in debug mode

[Bart Janssens]

Hi guys,

I've followed the recent discussion about compilation performance,
it's good to know things are getting better and hopefully support for
the new standard will help even more.

Currently, my main problem is not so much the compile time itself, but
how much RAM gets used in debug mode (GCC 4.5.2 on ubuntu 11.04). I'm
still using proto from boost 1.45, would the recent changes help
anything in reducing RAM usage in debug mode? Is anyone aware of
tweaks for GCC that reduce memory usage, but still produce useful
debug info (just using -g now, no optimization)?

I've gotten to the point where a compile can use upwards of 1.5GB for
a single test, resulting in much swapping, especially when compiling
with make -j2 (which I try to remember not to do, now ;).

Regards,

-- 
Bart
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto