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

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: >

Re: [proto] Clang compile times

-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

Re: [proto] Holding children by copy or reference

. -- 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

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

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

Re: [proto] Proto v5

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

Re: [proto] Proto v5

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

Re: [proto] problems with proto::matches

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

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

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

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

Re: [proto] proto-11 progress report

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

Re: [proto] Refining the Proto concepts

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

Re: [proto] _unpack transform

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

Re: [proto] _unpack transform

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

Re: [proto] _unpack transform

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

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

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

Re: [proto] proto-11 progress report

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

Re: [proto] proto-11 progress report

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

Re: [proto] proto-11 progress report

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

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

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

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

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

Re: [proto] Hold terminals by smart reference

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

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

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

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

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

Re: [proto] restructuring expression

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] Restructuring noses in generator

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

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

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

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

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

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

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

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

. :-) -- 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] Held nodes by value for Fundamental types

-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

Re: [proto] user docs for advanced features

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] user docs for advanced features

-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

Re: [proto] Problems with unary function node

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

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

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

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

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

Re: [proto] Compiling in debug mode

, 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. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto

Re: [proto] [phoenix] not playing nice with other libs

On 5/5/2011 12:32 AM, Eric Niebler wrote: I'll also need to investigate why Proto depends on BOOST_MPL_LIMIT_METAFUNCTION_ARITY. Proto no longer depends on BOOST_MPL_LIMIT_METAFUNCTION_ARITY. At least, not on trunk. I'm working on pre-preprocessing stuff. So far, it doesn't seem to be having

Re: [proto] Manipulating an expression tree

this twice.) Have you read the Expressive C++ article series on C++Next? It covers grammars and transforms step-by-step. Here's the first one in the series: http://cpp-next.com/archive/2010/08/expressive-c-introduction/ HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com

Re: [proto] Manipulating an expression tree

in the form of the tag. That's how a plus node is distinguished from a minus node, for instance. If you need to compute intermediate values, you can use a transform to build a parallel structure. -- Eric Niebler BoostPro Computing http://www.boostpro.com signature.asc Description: OpenPGP digital

Re: [proto] invalid use of incomplete type 'detail::uncvref...'

On 3/1/2011 3:15 AM, Hossein Haeri wrote: Hi Eric, boost/proto/matches.hpp:391:13: error: invalid use of incomplete type 'struct boost::proto::detail::uncvrefarity_caller::CanBeCalledPlus2, mpl_::integral_cint, 2 ::type' Now look at how you've defined CanBeCalled: templatetypename Fun

Re: [proto] Nested Transforms

On 2/28/2011 11:40 PM, Nate Knight wrote: On Feb 26, 2011, at 4:55 AM, Eric Niebler wrote: I think I know what's causing this. Can you try compiling with BOOST_PROTO_STRICT_RESULT_OF? Eric, Thanks for the information. Compiling with BOOST_PROTO_STRICT_RESULT_OF allows the first

Re: [proto] proto performance

is the same with each iteration? -- 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 performance

is like ranging from 10 to 50%. That's weird. -- 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] Nested Types in Transforms

On 2/16/2011 10:23 PM, Hossein Haeri wrote: Hi Eric, When you access a member of a class template, it causes the template to be instantiated. CanBeCalled cannot legally be instantiated with two function types. Hence the error. Function types? Are you really speaking of types of ordinary C

Re: [proto] Matching terminals holding a function pointer

FunctionPointer : proto::and_ proto::terminal _ , proto::if_ is_pointer proto::_value () , proto::if_ is_function remove_pointer proto::_value () {}; HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com

Re: [proto] Default constructor of proto::extends

On 2/7/2011 6:01 AM, Antoine de Maricourt wrote: Hi Eric, is there any reason why the default ctor of proto::extends uses the following form: extends() : proto_expr_() {} instead of simply extends() {} I use proto::extends over expressions that hold x86 SIMD registers

Re: [proto] Active operator/function generation checking

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. You might also consider a debugging mode controlled with a compiler switch, where things are checked up-front. Just a suggestion. -- Eric Niebler BoostPro Computing

Re: [proto] : Proto transform with state

On 11/18/2010 4:56 AM, Eric Niebler wrote: I think Proto transforms need a let statement for storing intermediate results. Maybe something like this: struct RenumberFun : proto::fold _ , make_pair(fusion::vector0(), proto::_state) , let _a

Re: [proto] : Proto transform with state

On 1/29/2011 7:49 PM, Eric Niebler wrote: Bills be damned. I just committed to trunk an implementation of proto::let, along with tests and reference docs. End-user docs are still todo. sigh As often happens, I woke up this morning knowing this code was broken, so I pulled it. I think I finally

[proto] new proto article, please vote it up

There's a new article about proto on cpp-next.com. Go to the following reddit page and vote it up. Thanks! http://www.reddit.com/r/cpp/comments/f9ek6/expressive_c_expression_optimization_eliminating/ -- Eric Niebler BoostPro Computing http://www.boostpro.com

Re: [proto] Proto Transform Questions

}; terminalint::type i = {42}; display_expr( (a+b+c)[i] ); display_expr( Vectorize()((a+b+c)[i]) ); } HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org

Re: [proto] Adding stuff in proto operator

? If yes, Eric, any objections that I merge this into trunk ? I made a few adjustments and committed it myself. Thanks, Joel! -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org

Re: [proto] expanding Proto's library of callables

of Phoenix placeholders, where in the index is a parameter: when terminalplaceholder_ , _at(_state, _value) For the times when the index is not a parameter, you can easily do: _at(_state, mpl::int_N()) -- Eric Niebler BoostPro Computing http://www.boostpro.com

Re: [proto] expanding Proto's library of callables

On 12/28/2010 11:43 AM, Thomas Heller wrote: Eric Niebler wrote: On 12/28/2010 5:39 AM, Thomas Heller wrote: I just saw that you added functional::at. I was wondering about the rationale of your decision to make it a non template. My gut feeling would have been to have proto::functional

Re: [proto] Adding stuff in proto operator

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. but let's I have some array/matrix DSEL going on. I want to test if two expression containing said matrix has compatible size

Re: [proto] Adding stuff in proto operator

Bingo. --Original Message-- From: Joel Falcou Sender: proto-boun...@lists.boost.org To: Discussions about Boost.Proto and DSEL design ReplyTo: Discussions about Boost.Proto and DSEL design Subject: Re: [proto] Adding stuff in proto operator Sent: Dec 28, 2010 5:35 PM Disregard last

Re: [proto] looking for an advise

On 12/27/2010 5:26 AM, Joel Falcou wrote: 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

Re: [proto] [Spirit-devel] [Spirit Development] Bug in today's boost_trunk -- ambiguous operator

to disable the troublesome overload. -- 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] [Spirit-devel] [Spirit Development] Bug in today's boost_trunk -- ambiguous operator

(Sorry for the top-post) Just because a type is a Fusion sequence, that doesn't mean it has boost::fusion as an associated namespace. I'm asking why boost::fusion::operator is in the overload set. Eric Sent via tiny mobile device -Original Message- From: Hartmut Kaiser hartmut.kai

Re: [proto] phoenix 3 refactoring complete.

to documentation writing and checking for BLL compatibility ... This is awesome news, Thomas. You should send this around to the boost developers list. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org

Re: [proto] [Spirit-devel] [Spirit Development] Bug in today's boost_trunk -- ambiguous operator

are proto sequences now). Proto's overload for operator() is a valid choice for this, as is fusions operator(). I'm cc'ing Eric and Christopher, perhaps they have an idea how to proceed. I suggest defining a Fusion trait, is_less_then_comparable, and define it for the built-in Fusion sequences

Re: [proto] current state

deprecated. Despite the fact that they're simpler for some things, I'd say avoid contexts. They won't get you as far as transforms. P.S. Eric, there is a bug in proto::display_expr, I wrote about it (and posted a patch) in comments to your Playing with syntax article on cpp-next, could you

[proto] expanding Proto's library of callables

'em and use 'em. Thoughts? -- 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] grammars, domains and subdomains

, please clarify. -- 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] grammars, domains and subdomains

On 12/9/2010 10:51 AM, Thomas Heller wrote: Eric Niebler wrote: On 12/8/2010 5:30 PM, Thomas Heller wrote: I don't really now how to do it otherwise with the current design. There is really only this part of the puzzle missing. If it is done, we have a working and clean Phoenix V3

Re: [proto] grammars, domains and subdomains

On 12/8/2010 5:30 AM, Thomas Heller wrote: Eric Niebler wrote: On 12/7/2010 2:37 PM, Thomas Heller wrote: So, How to handle that correctly? Yup, that's a problem. I don't have an answer for you at the moment, sorry. I think i solved the problem. The testcase for this solution is attached

Re: [proto] : Proto transform with state

On 12/6/2010 4:50 PM, Thomas Heller wrote: Eric Niebler wrote: I played with the let transform idea over the weekend. It *may* be possible to accomplish without the two problems I described above. See the attached let transform (needs latest Proto trunk). I'm also attaching the Renumber

Re: [proto] grammars, domains and subdomains

So, How to handle that correctly? Yup, that's a problem. I don't have an answer for you at the moment, sorry. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman

Re: [proto] : Proto transform with state

On 11/18/2010 3:31 PM, Eric Niebler wrote: On 11/18/2010 1:45 PM, Thomas Heller wrote: Eric Niebler e...@... writes: It's REALLY hard. The let context needs to be bundled with the Expr, State, or Data parameters somehow, but in a way that's transparent. I don't actually know if it's possible

Re: [proto] Proto documentation, tutorials, developer guide and general Publis Relations

On 12/4/2010 12:10 PM, joel falcou wrote: On 04/12/10 18:01, Eric Niebler wrote: 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

Re: [proto] problem with constness of operator return types

scenarios that are busted by this const stuff, please let me know. -- 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 transform with state)

on this! -- 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 transform with state

On 11/17/2010 2:18 PM, joel falcou wrote: 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

[proto] latest proto article is posted

This one has little directly to do with Proto, but lays the foundation for a deeper understanding of Proto transforms and why they are necessarily purely functional. http://cpp-next.com/archive/2010/11/expressive-c-fun-with-function-composition/ -- Eric Niebler BoostPro Computing http

Re: [proto] Using proto with expressions containing matrices from the EIgen library

to do with 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] Visitor Design Pattern

::actor to phoenix::lambda. But what about the existing phoenix::lambda? Rename it to protect (from Boost.Lambda)? See Joel's response. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http

Re: [proto] Visitor Design Pattern

On 10/25/2010 4:44 PM, Joel de Guzman wrote: On 10/26/2010 4:30 AM, Eric Niebler wrote: [...] Voila! The implementation is trivial: one specialization of proto::when on the new (incomplete) proto::external type. God, why didn't I think of this sooner? The naming issue goes away

Re: [proto] Visitor Design Pattern

On 10/23/2010 10:45 AM, Thomas Heller wrote: On Saturday 23 October 2010 19:30:18 Eric Niebler wrote: On 10/23/2010 10:12 AM, Eric Niebler wrote: I've tweaked both the traversal example you sent around as well as my over toy Phoenix. Tell me what you guys think. Actually, I think it's better

Re: [proto] Visitor Design Pattern

On 10/23/2010 5:10 PM, Joel de Guzman wrote: On 10/24/2010 2:18 AM, Thomas Heller wrote: On Saturday 23 October 2010 19:47:59 Eric Niebler wrote: On 10/23/2010 10:45 AM, Thomas Heller wrote: Why not just rule? Less characters to type. I almost called it rule, but *everything* in Proto

Re: [proto] Visitor Design Pattern

don't think that's what Thomas and I are doing. vW-grammars change the descriptive power of grammars. But we don't need more descriptive grammars. Thomas and I aren't changing the grammar of Phoenix at all. We're just plugging in different actions. The grammar is unchanged. -- Eric Niebler BoostPro

Re: [proto] Visitor Design Pattern

On 10/22/2010 12:33 AM, Thomas Heller wrote: On Friday 22 October 2010 09:15:47 Eric Niebler wrote: On 10/21/2010 7:09 PM, Joel de Guzman wrote: Check out the doc I sent (Annex A). It's really, to my mind, generic languages -- abstraction of rules and templated grammars through metanotions

Re: [proto] Visitor Design Pattern

On 10/22/2010 10:01 AM, Thomas Heller wrote: I think this is the simplification of client proto code we searched for. It probably needs some minor polishment though. snip Hi Thomas, this looks promising. I'm digging into this now. -- Eric Niebler BoostPro Computing http://www.boostpro.com

Re: [proto] Visitor Design Pattern

-consulting.com Sender: proto-boun...@lists.boost.org Date: Sat, 23 Oct 2010 09:29:27 To: proto@lists.boost.org Reply-To: Discussions about Boost.Proto and DSEL design proto@lists.boost.org Subject: Re: [proto] Visitor Design Pattern On 10/23/2010 5:36 AM, Eric Niebler wrote: On 10/22/2010 10:45

Re: [proto] Thoughts on traversing proto expressions and reusing grammar

On 10/20/2010 11:41 PM, Thomas Heller wrote: On Thu, Oct 21, 2010 at 7:50 AM, Thomas Heller thom.hel...@googlemail.com wrote: On Thursday 21 October 2010 05:11:49 Eric Niebler wrote: On 10/20/2010 7:49 AM, Thomas Heller wrote: snip Here it goes: namespace detail { template

Re: [proto] Visitor Design Pattern

with a domain expert to make that happen. Any volunteers? :-) -- 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] [phoenix3] New design proposal

hard is it to add a new statement, for instance? -- 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] Phoenix3 at BoostCon?

On 10/17/2010 8:20 AM, Hartmut Kaiser wrote: Eric Niebler wrote: IMO, Phoenix3 is one of the most important Boost development over the past year. There should unquestionably be a presentation at BoostCon about it. I think I'll go, and would at the very least like to help. Is anybody else

Re: [proto] Thoughts on traversing proto expressions and reusing grammar

On 10/8/2010 12:12 AM, Thomas Heller wrote: On Thursday 07 October 2010 23:06:24 Eric Niebler wrote: On 10/4/2010 1:55 PM, Eric Niebler wrote: The idea of being able to specify the transforms separately from the grammar is conceptually very appealing. The grammar is the control flow

Re: [proto] Thoughts on traversing proto expressions and reusing grammar

On 10/4/2010 12:20 PM, Thomas Heller wrote: On Mon, Oct 4, 2010 at 8:53 PM, joel falcou joel.fal...@lri.fr wrote: On 04/10/10 20:45, Eric Niebler wrote: I'm not opposed to such a thing being in Proto, but I (personally) don't feel a strong need. I'd be more willing if I saw a more strongly

Re: [proto] Thoughts on traversing proto expressions and reusing grammar

On Mon, Oct 4, 2010 at 12:43 PM, Thomas Heller thom.hel...@googlemail.comwrote: On Mon, Oct 4, 2010 at 8:45 PM, Eric Niebler e...@boostpro.com wrote: On 10/4/2010 6:49 AM, Thomas Heller wrote: Hi, I spent some time on thinking how one could make the traversal of a proto expression

[proto] latest proto post

This one is likely to start a language war. Read the article. Vote it up. Enjoy. http://www.reddit.com/r/programming/comments/diddg/expressive_c_why_template_errors_suck_and_what/ -- Eric Niebler BoostPro Computing http://www.boostpro.com signature.asc Description: OpenPGP digital signature

Re: [proto] question about sub-domains

;-) This is really ok. I'm very glad this feature is finding real-world uses. Push it further and send us status updates. :-) -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org

Re: [proto] for your review: intro to a series of blog posts aboutproto and phoenix v3

The preview link expires after a certain amount of time. Also, I'm currently in the process of incorporating various feedback. I'll post a fresh link later. Eric Sent via tiny mobile device -Original Message- From: OvermindDL1 overmind...@gmail.com Sender: proto-boun

Re: [proto] for your review: intro to a series of blog posts about proto and phoenix v3

messages. and tool support is somewhat lacking as far as I know, being pretty much limited to STLFilt. Maybe I'm just too long in the tooth for this! Still, great piece, and I look forward to subsequent installments. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

Re: [proto] So I heard proto make AST ...

On 8/10/2010 2:52 PM, joel.fal...@lri.fr wrote: Eric Niebler wrote: A pre-order traversal, pushing each visited node into an mpl vector? How about: snip I'm on a tiny mobile, but my idéa was to have such algo as proto transforms grammar Good. Now if you are saying that Proto's existing

Re: [proto] Proto v4.1

On 8/4/2010 1:35 PM, joel falcou wrote: 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

[proto] Proto v4.1

notes: http://tinyurl.com/242ln7f FYI, most of these changes were motivated by the Phoenix3 work. That sure is one demanding DSEL. -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http

Re: [proto] using BOOST_PROTO_EXTENDS_FUNCTION()

BOOST_PROTO_EXTENDS_FUNCTION isn't going to work for you and you need to define them by hand. HTH, -- 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] So I heard proto make AST ...

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

  1   2   >