Re: [proto] Other methods for embedding DSL in C++
On 26/07/10 21:36, Manjunath Kudlur wrote: If you have to do heavy-weight things like optimizing the generated AST, you got to anyway do it at runtime. You can still inspect the code, transform it, etc at runtime. (Note : I am not trying to defend the runtime retained execution model. I am a big fan of Proto. I am just trying to understand the differences and see where each model makes sense). I'm biased as I mostly do HPC DSL but for me wastiung RT cycles to do stuff which are fully statis is useless. The only thign RT shoudl bring is specialization over RT onyl data (liek data set size etc). ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Other methods for embedding DSL in C++
On 26/07/10 21:52, Eric Niebler wrote: I confess I'm having a hard time seeing how the code posted in Manjunath's original email could result in something that can be introspected at runtime. Does it generate byte code? A runtime polymorphic AST? And the JIT ... does it actually generate machine code that then gets executed? Yeah screw introspection. It usually generates C code in a string then JIT it using w/e compiler is lying around. Manjunath asked about why this technique is popular in industry. I don't know; I've never heard about it before. Is it because it's easier then programming with expression templates? Maybe had proto been available earlier we'd see more ET-based DSELs today. That could just be my ego talking. ;- Popular != pushed by Intel/Google. For me it's a bad solution. Hence why we look at CT-EDSL ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Other methods for embedding DSL in C++
On 26/07/10 22:12, Eric Niebler wrote: Convincing people of what in your article? That C++ EDSL are good thanks to templae meta-programming in general That compile-time introspection is a Good Thing? Among other What are the complaints you hear most often? It's C++ ?!? Why not making a real compiler ? Seriously, you CAN NOT get that fast, you're cheating Who use C++ anyway ? Again Expression Tempaltes, ok, that's old, please move on how do you compare to insert JAVA based library, that's real industrial strength system ! authors should focus on real benchmarks (like dot product) insetad of this lengthy useless implementation description (Which article, btw?) Among other: http://dl.dropbox.com/u/3819406/edsl/parco_07.pdf http://dl.dropbox.com/u/3819406/edsl/europar_08.pdf http://dl.dropbox.com/u/3819406/edsl/pact_09.pdf Note that most predates proto but are basically hand made C++ EDSL with Expression Templates. The pact paper is made out of proto though. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:08, Eric Niebler wrote: That would be awesome, Joel! I'll count on you for helping me making those looking nice :p What's the easiest ? getting a proto-tree branch or what ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 27/07/10 15:08, Eric Niebler wrote: That would be awesome, Joel! WHat's the easiest in term of code ? I can bring up some git repo or shoudl I work in some svn branches of proto somewhere at boost ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Proto v4.1
On 04/08/10 01:00, Eric Niebler wrote: Most folks here don't know this, but the version of Proto y'all are using is actually v4. (Three times the charm wasn't true for Proto.) Anyway, there are so many goodies coming in Boost 1.44 that think of it as Proto v4.1. I just posted the release notes for this version to give you guys an heads-up of the coming changes. There are a few very small breaking changes that you should take careful note of. Most of the interesting stuff is in the new features: sub-domains and per-domain control of as_expr and as_child. Have a look. Let me know if you have any questions: Boost 1.44 release notes: http://tinyurl.com/242ln7f FYI, most of these changes were motivated by the Phoenix3 work. That sure is one demanding DSEL. Would you like me to write some lines on my compile-time performance and figures to include somewhere in the doc. I remember you wanted to do that at some point. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
On 11/08/10 17:52, Eric Niebler wrote: I don't exactly recall the details of Joel's technique. My experiments to separate transforms from grammars were largely unsuccessful because control flow often need pattern matching. I'd like to see alternate designs. Mine was just a post-order traversal by a visitor that could be specialized on node's tag Ah, but the control flow of this transform depends on pattern matching (i.e., the grammar) to dispatch to the correct handler. I'm interested to see what this arity calculation would look like with a tree traversal. Last time I tried, i ended up needing a meta-function that gave you the arity of any tag. Then you did a fold of max over the tree traversal. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] So I heard proto make AST ...
This is kind of like Proto's evaluation contexts, IIUC. I'm not wild for them because often just the tag isn't enough information to find the right handler. But maybe it covers enough use cases and can be made easier to use. Right now, proto has an eval function that takes an expression and an evaluation context, but the user is responsible for the flow control. Maybe there should be a pre_order_eval and post_order_eval that takes on the control flow responsibilities. Yes but here each tag specialization leaves in its own function object and not as an operator()(). For sepcific need, we can specialize based on tag+type of visitor+type of visitee. Tags don't have arities. E.g. nothing prevents someone from creating an expression with tag::plus and 5 children. Yes but the same way proto operator has the expected behavior by defualt, one can expect they have expected arity. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Funky exercie: subset of Boost::parameters using proto
Got some error trying to compile this vs boost :: trunk j...@dell-desktop:~/Desktop$ time g++-4.3 -O3 -c options.cpp -I./ -I/usr/local/include/boost-trunk options.cpp: In member function ‘typename boost::option_exprExpr::resultconst boost::option_exprExpr ()(Option, Default)::type boost::option_exprExpr::operator()(const Option, const Default) const’: options.cpp:103: error: wrong number of template arguments (3, should be 2) /usr/local/include/boost-trunk/boost/proto/proto_fwd.hpp:435: error: provided for ‘templateclass Expr, class Grammar struct boost::proto::matches’ /usr/local/include/boost-trunk/boost/mpl/assert.hpp: At global scope: /usr/local/include/boost-trunk/boost/mpl/assert.hpp: In instantiation of ‘mpl_::assert_arg_pred_notint’: options.cpp:103: instantiated from here /usr/local/include/boost-trunk/boost/mpl/assert.hpp:148: error: ‘int’ is not a class, struct, or union type /usr/local/include/boost-trunk/boost/mpl/assert.hpp:149: error: ‘int’ is not a class, struct, or union type ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
On 24/10/10 11:53, Joel de Guzman wrote: Am I the only one thinking that actor should be more a part of proto than phoenix? I'd love to use such a generic extension mechanism for Spirit too, for example. I *need* it for nt2 too, makes some optimisation far simpler than before. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
You could pass it as state OK or bundle it with the external transforms. All you need is a nested when template. Does that help? A short example of this for my poor 7am self without coffee ;) ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Visitor Design Pattern
On 26/10/10 19:44, Eric Niebler wrote:
struct my_actions_with_state
{
// specializations to look up transforms
// using rules:
templatetypename Rule
struct when;
// any ol' state can go here:
int my_state;
};
Now, you can pass an instance of my_actions_with_state as a data
parameter. Proto will use the nested when template to find transforms,
and your transforms can use the my_state member at runtime to do whatever.
Does that help
Oh snap ! Yes :D
Thansk for the head up
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Using proto with expressions containing matrices from the EIgen library
That's a tough one :/ Main problem is probably the fact you can't control when/Where eigen do his bidding. Best shot is to externally make eigen temporary proto terminals, write a grammar that disable operators onthem and then write a transform dealing with the composite E.T AST. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] : Proto transform with state
On 17/11/10 19:46, Eric Niebler wrote: See the attached code. I wish I had a better answer. It sure would be nice to generalize this for other times when new state needs to bubble up and back down. Just chiming in. We had the exact same problem in quaff where needed to carry on a process ID over the trasnform of parallel statement. If it can make you worry less Eric, we ended with the exact same workaround. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Externalizing grammar pattern matching
On 23/11/10 17:20, Eric Niebler wrote:
On 11/23/2010 10:19 AM, Joel Falcou wrote:
So, question is: is there a way to have an extensible list of
whenpattern,rule that can be extended from the outside, something
like a proto::switch_ but with patterns instead of tag ?
No. The best you can do is document how to define a new Proto algorithm
from an old one:
struct Old : proto::or_ ... {};
struct New : proto::or_ my_stuff, Old {};
Now everywhere in your library that you have the Old algorithm
hard-coded, you need to make it a template parameter so that your stuff
can be used with an extended algorithm.
Can't the new extrnal_transform be of any help ?
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Proto documentation, tutorials, developer guide and general Publis Relations
On 04/12/10 18:01, Eric Niebler wrote: Something along those lines would be a big improvement. I've gotten better at explaining Proto since I wrote those docs, and they could use a major facelift. I still like the fundamental idea of structuring the users guide around the idea of Proto as a compiler construction toolkit, with sections for front-end, intermediate form, and back-end. But before we get to that, there should be a Not-So-Quick Start with examples that gets people going. The structure is rather good and I (we) liked it. But some gallery of detailed samples could be nice to have a long-standing work-item to go through the docs and examples and The contexts must go. Great 4/ Maybe more diverse examples coudl eb turned into full fledged, detailed, step by step tutorial. map_assing map_assing? OK my dyslexia stroke again: *map_assign* Yes, this an some other newer features are not described in the users' guide at all. That includes sub-domains, per-domain control over as_child and as_expr, external transforms, and now the expanded set of functional callables. and the member thing or is it still in flux ? Any and all contributions are welcome. But no assing please. Promise ;) no assing :€ What is this? Are you referring to cpp-next.com? I'm pretty committed to finishing the article series I started there, and it wouldn't be right to move it elsewhere at this point. Once I sent this, I remembered abotu c++-next. Dunno if you could use it for more proto expsoure through tutorial stuff ? I wasn't asking you to move anyway :) ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] phoenix 3 refactoring complete.
nice xmas present :D can't wait for the doc ;D ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] looking for an advise
On 27/12/10 11:02, Maxim Yanchenko wrote: Hi Eric and other gurus, Sorry in advance for a long post. I'm making a mini-language for message processing in our system. It's currently implemented in terms of overloaded functions with enable_ifmatchGrammar dispatching, but now I see that Dont. this increases copiel time and provide unclear error. Accept anykind of expression adn use matches in a static_assert with a clear error ID. (a) I'm reimplementing Phoenix which is not on Proto yet in Boost 1.45.0 (that's how I found this mailing list). It would be great to reuse what Phoenix has; Isn't it in trunk already Thomas ? (b) I need to do several things on expressions and I don't know what would be the best way to approach them all. Here is a background. Every message is a multiset of named fields (i.e. is a multimap FieldName-FieldValue). I have a distinct type for each FieldName, so I can do some multiprogramming on sets of FieldNames, like making generating a structure that will hold values of the fields I need, by list of field names (e.g. fusion::map). While processing a message, I can do some checks like if particular field is present, if it's equal or not to some value, if it matches a predicate etc. They are implemented as a set of predicate functions condition like template class Msg, class Expr typename boost::enable_if proto::matchesExpr, proto::equal_to proto::_, proto::_ , bool::type condition( const Msg msg, const Expr expr ) with various condition grammars in enable_ifmatches... Again, use matches inside the function body. (a) everything runs on enable_if. I expect it to become more concise and clean if I use either transforms or contexts. You need none. Put your grammar into a domain with a proper context and proto will check operators overload for you. (b) a lot of Phoenix is basically reimplemented from scratch (thanks Eric, with Proto it was very easy to do!). But I don't know how to extend Phoenix so it could work in my expressions with my things like any_field, optional, mandatory etc. Better see what Thomas has up his sleeves in Phoenix. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Adding stuff in proto operator
Here i smy use case. I guess Eric answer will be do this at evaluation time but let's I have some array/matrix DSEL going on. I want to test if two expression containing said matrix has compatible size before creating a proto ast node. e.g if a,b are matrices, a + b should assert if size(a) != size(b) (in the matlab meaning of size). Now i can do the check when evaluating the expression before trying to assign it BUT it irks me that the assert triggers inside the matrix expression evaluator instead of at the line said + was wrongly called. Could we have some way to specify code to call before returning the a new operator AST node, shoudl I overload operators myself ? Should I stick with the assert in eval policy and try to come up with way to tell the user which operators faile din which expression, did I miss the obvious ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
On 28/12/10 23:13, Eric Niebler wrote: On 12/28/2010 5:05 PM, Joel Falcou wrote: Here i smy use case. I guess Eric answer will be do this at evaluation time Do this at evaluation time. Just kidding. See :p I was *sure* you will say that :p You missed the Generator parameter to proto::domain. It's a unary function object that accepts all new proto expressions and does something to it. That something can include asserting if matrix/vector sizes don't match. Oh snap ! Of course. I just have to make my generator do the same stuff than normal proto generator except asserting before. I also see that i can make this Generator subject to some of our policy to enable?disable this at compile-time. OK Sold :D ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
Last question. The geenrator awaits a Expr as parameters, what can be the way to specialize this operator() dependign on the tag passed to the generator ? Extract tag_of out of Expr and then dispacth internally ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
Disregard last question. a generator is just a callable, so i can use a grammar as a generator I guess hence using the grammar to dispacth the proper actions on my ast construction. Am I right ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
OK, small road bump.
I tried a simple grammar as geenrator thingy but using the idea that i
didnt wanted to replicate all possible generator out there.
So i made a template grammar taking a Generator and doing thing around:
struct print_tag : proto::callable
{
typedef void result_type;
templateclass X void operator()(X const) const
{
std::cout typeid(typename proto::tag_ofX::type).name() \n;
}
};
templateclass Generator
struct debug_generator
: proto::when proto::_
, proto::and_ print_tag(proto::_)
, Generator(proto::_)
{};
I then took the Calc2 example and changed the calculator_domain to be :
struct calculator_domain
:
proto::domaindebug_generatorproto::generatorcalculator_expression
{};
Boost version is 1.45
The full modified code is : http://codepad.org/41nnNNwf
Alas, I got a lump of errors as specified here : http://codepad.org/4hnylfvQ
Am I missing something or is the and_ not working like I thougt it was
as a transform.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Adding stuff in proto operator
Error found.
The problem was in the and_impl transform. It uses comma operator to
chain calls to each and_ alternatives.
However, when this is used in a grammar used as a Generator, it enters a
subtle infinite loop as each comma
want to build an expression with the newly generated expression.
I locally modified proto this way in boost/proto/matches.hpp :
templateBOOST_PP_ENUM_PARAMS(N, typename G), typename Expr, typename
State, typename Data
struct _and_implproto::and_BOOST_PP_ENUM_PARAMS(N, G), Expr, State, Data
: proto::transform_implExpr, State, Data
{
#define M0(Z, N,
DATA)\
typedef
\
typename proto::whenproto::_, BOOST_PP_CAT(G,
N)\
::template implExpr, State,
Data\
BOOST_PP_CAT(Gimpl,
N); \
/**/
BOOST_PP_REPEAT(N, M0, ~)
typedef typename BOOST_PP_CAT(Gimpl, BOOST_PP_DEC(N))::result_type
result_type;
result_type operator()(
typename _and_impl::expr_param e
, typename _and_impl::state_param s
, typename _and_impl::data_param d
) const
{
// Fix: jfalcou - 12/29/2010
// This allow and_ to be used in grammar used as generator
// by not using comma which caused an infinite loop
#define M1(Z,N,DATA) \
BOOST_PP_CAT(Gimpl,N)()(e,s,d);\
/**/
// expands to G0()(e,s,d); G1()(e,s,d); ... G{N-1}()(e,s,d);
BOOST_PP_REPEAT(BOOST_PP_DEC(N),M1,~)
return BOOST_PP_CAT(Gimpl,BOOST_PP_DEC(N))()(e,s,d);
}
#undef M1
#undef M0
};
instead of using comma, I just generate N-1 application of GimplN and
return the last Gimpl call.
Is this fix acceptable or am I doing something wrong all together ?
If yes, Eric, any objections that I merge this into trunk ?
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Active operator/function generation checking
I'm trying to polish the last layer of compile time error handling in nt2. my concern at the moment is that, if have a function foo(a,b) that works on any real a and any char b, i dont want my foo function working on nt2 container to work with nothing but matrix of real and matrix of char. nt2 has a is_callable_with metafunction that basically check for this on the scalar level. Considering the huge amount of functions nt2 has to support and their complex type requirement, grammar are a bit unusable here. Is it OK to have a custom nt2 generator that basically static_assert over is_callable_with to prevent wrong container expression to be built and hence ends up in error waay far in the expression evaluation code ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Active operator/function generation checking
On 31/01/11 04:38, Eric Niebler wrote: This is a judgment call that only you, as library author, can make. If doing the checking early imposes too high a compile-time requirement, then it may make sense to delay it until it's less expensive to do, and accept worse error messages. *nods* But at least, I am not doing something completely stupid at this level. You might also consider a debugging mode controlled with a compiler switch, where things are checked up-front. Just a suggestion. I was thinking of this too, and add some NT2_COMPILE_TIME_DEBUG mode. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 11:57, Eric Niebler wrote: On 2/20/2011 5:52 PM, Joel Falcou wrote: 1/ how do you measure performances ? Anything which is not the median of 1-5K runs is meaningless. You can see how he measures it in the code he posted. I clicked send too fast :p 2/ Don't use context, transform are usually better optimized by compilers That really shouldn't matter. Well, in our test it does. At least back in gcc 4.4 3/ are you using gcc on a 64 bits system ? On this configuration a gcc bug prevent proto to be inlined. Naive question: are you actually compiling with optimizations on? -O3 -DNDEBUG? And are you sure the compiler isn't lifting the whole thing out of the loop, since the computation is the same with each iteration? Oh yeah I forgot these. On my machine (mac osx dual core intel with g++4-5) i have a 25% speed up by proto ... ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 11:55, Karsten Ahnert wrote: On 02/20/2011 11:57 AM, Eric Niebler wrote: It gcc 4.4 on a 64bit machine. Of course, I compile with -O3. Ding! welcome to gcc-4.4 64bits compiler hellfest. Try 4.5, 4.4 64bits can't inlien for w/e reason. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] proto performance
On 20/02/11 12:41, Eric Niebler wrote: On 2/20/2011 6:40 PM, Joel Falcou wrote: On 20/02/11 12:31, Karsten Ahnert wrote: It is amazing that the proto expression is faster then the naive one. The compiler must really love the way proto evaluates an expression. I still dont really know why. Usual speed-up in our use cases here is like ranging from 10 to 50%. That's weird. Well, for me it's weird in the good way so I dont complain. Old version of nt2 had cases where we were thrice as fast as same vector+iterator based code ... ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] My own lambda for MSM / wish list
On 14/03/11 04:49, Eric Niebler wrote: Exciting stuff! Truly Christophe, your ideas re decltype and EDSLs in C++ are revolutionary. But unfortunately, I fear it will require a revolution. This is all do-able, but the changes to MPL, Proto and even to Phoenix in the case of the lambda capture stuff would require breaking API changes. The main problem is that we still segregate type operations from their runtime counterpart, this leads me to ... As for MPL and Proto, someone needs to sit down and do some hard thinking about what meta-programming will look like in C++0x. I suspect it'll look less like today's MPL and Proto, and much more like what you envision. It's a huge opportunity for someone to do some really ground-breaking work. .. the talk from Matt Calabrese last year at boostcon with the MPL/Fusion hybrid using decltype and auto. I think this is an interesting venture all in all and should be extended. I have the same kind of ideas Christophe plus a few other (including a real meta-DAG structure). Maybe we should get Matt in our boat and try hammering stuff ? ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] My own lambda for MSM / wish list
On 14/03/11 22:28, Christophe Henry wrote: .. the talk from Matt Calabrese last year at boostcon with the MPL/Fusion hybrid using decltype and auto. I think this is an interesting venture all in all and should be extended. Yes, I have this in mind too. I think it is worthy of *at least* consideration. MAtt said some stuff was still edgy but the core is probably here. Sure! Count me in! And add Gordon to the pool. As for who working when and how long, take into consideration i have some part of my own research programm trying to get started on that, so I can dedicate more than just my free time to this. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] Latest proto commit on trunk.
I got these error compiling NT2 with proto trunk /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:56: error: 'M0' has not been declared /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: expected identifier before '~' token /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: expected ')' before '~' token /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: ISO C++ forbids declaration of 'BOOST_PP_REPEAT_1_BOOST_PROTO_MAX_ARITY' with no type /usr/local/include/boost-latest/boost/proto/detail/decltype.hpp:67:1: error: expected ';' before '~' token Our code is : #include boost/config.hpp #include boost/detail/workaround.hpp #if BOOST_WORKAROUND(BOOST_MSVC, = 1600) defined BOOST_NO_DECLTYPE #undef BOOST_NO_DECLTYPE #endif #include boost/proto/detail/decltype.hpp #define NT2_DECLTYPE(EXPR, TYPE) BOOST_PROTO_DECLTYPE_(EXPR, TYPE) Is detail/decltype.hpp a no-go to reuse this way ? As for why we do this, we have to fight against some MSVC bug w/r to decltype that PROTO_DECLTYPE seemed to fix. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Latest proto commit on trunk.
On 09/05/11 21:12, Eric Niebler wrote: FWIW, this was due to a missing #include, which I've since fixed. This *should* work again, but it's not part of Proto's public documented interface. I reserve the right to break your code. ;-) No problem. This is anyway some ugly fix. We have to slaps MSVC in the face harder. Thanks for the timely commit, I'll report nt2 compile time improvement as soon as my box is not sluggish anymore ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] Latest proto commit on trunk.
On 09/05/11 20:36, Eric Niebler wrote: Right, that's not going to work. I'm surprised it ever did. it was long shot by us I confess. I'll repent I promise Can you you boost/typeof.hpp For w/e reason it fails horribly in flames and brimstone under MSVC2010 in our test cases. PROTO_DECLTYPE dont ... ___ 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
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] Grouping expressions
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
Re: [proto] Held nodes by value for Fundamental types
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
[proto] The proper way to compose function returning expressions
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
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] Restructuring noses in generator
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] [proto-11] expression extension
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
[proto] Who's using proto ?
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] [proto-11] expression extension
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] proto-11 progress report
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] fold_tree and grammar using external_transforms and state
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] fold_tree and grammar using external_transforms and state
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
