Roland Bock wrote:

On 09/24/2010 02:33 PM, Roland Bock wrote:

...

Hi,

ist there a way to access the grammar that was used to construct an expression?

I have defined a metafunction

template<class Left, class Right> struct grammar_less: mpl::false_ {};

which has specialization for some grammar combinations.

Now I want to define a function that can take two arguments so that

child0.grammar < child1.grammar

Any idea how to do that? My test-code is attached.

Regards,

Roland

Hi,

since I know the structure of the types in question, I can circumvent the problem as shown in the attached code. Not nice, but I could probably use it.

Regards,

Roland

you can compute that type information directly in your proto transform: struct sorted_argument_function: proto::and_ < proto::function<fun_terminal, proto::_, proto::_>, proto::if_ < grammar_less< proto::_value(proto::_child0(proto::_child1)) , proto::_value(proto::_child0(proto::_child2))>() > > {}; btw: there is a proto specific list: proto@lists.boost.org

On 9/24/2010 11:15 AM, Roland Bock wrote:

On 09/24/2010 04:52 PM, Thomas Heller wrote:

...

you can compute that type information directly in your proto transform:

struct sorted_argument_function: proto::and_ < proto::function<fun_terminal, proto::_, proto::_>, proto::if_ < grammar_less< proto::_value(proto::_child0(proto::_child1)) , proto::_value(proto::_child0(proto::_child2))>() > > {};

OK, admittedly, that looks a lot nicer, but in case I call something like

fun(b(0), 42));

the error messages are just horrible in both solutions...

The proto::and_ has two branches: proto::function and proto::if_. The proto::if_ is assuming: 1. That there are at least three child nodes 2. That child1 and child2 themselves have a child 3. That the child nodes of child1 and child2 are terminals The proto::function has only verified the first of these assumptions. You need to change it to validate the other two as well: struct function_argument : proto::function<proto::terminal<proto::_>, proto::_> {}; struct sorted_argument_function : proto::and_ < proto::function < fun_terminal, function_argument, function_argument >, proto::if_ < grammar_less < proto::_value(proto::_child0(proto::_child1)) , proto::_value(proto::_child0(proto::_child2)) >() > > {}; HTH, -- Eric Niebler BoostPro Computing http://www.boostpro.com

C++0x lambda functions unfortunately do not define result_type, which is required for most of the Boost.Iterator predefined adapters. Is there a recommended approach to use here? Right now I'm creating a generic wrapper object which determines the result_type using a decltype(), but that seems to be giving me problems on Linux (works fine on Windows). Not the result_of call itself, but something to do with the wrapper's default constructor. So I'm looking for a better solution.

On Fri, Sep 24, 2010 at 9:52 AM, Thomas Heller <thom.heller@googlemail.com> wrote:

btw: there is a proto specific list: proto@lists.boost.org

Why a separate list? IHMO you expose more people to advanced libraries like Spirit and Proto by using the main user or dev lists. This reminds me of the recent Joel Spolsky post http://blog.stackoverflow.com/2010/09/merging-season/ and his "rules". The usual [Spirit] or [Proto] "tags" in the subject are just fine, and AFAIK nobody's complained on the user or dev list about Spirit or Proto related messages. I know I'd prefer to see all Boost-related messages and topics on either boost-users@... or boost@.... My $0.02. --DD

On Fri, Sep 24, 2010 at 11:51 AM, Eric Niebler <eric@boostpro.com> wrote:

I agree with you, and it's perfectly OK to discuss Proto here. [...]

Thanks for chiming in and the background on the list's existence.

discussion about the Phoenix3 redesign [...] wasn't really appropriate for boost-dev or boost-user.

Well, that's quite debatable that the redesign of an OSS library is not proper for a dev list in the OSS project that library is hosted in. I'm not sure I agree and it's the essence of OSS to be open and upfront about everything. But it's just a philosophic objection, and I know nothing about the particulars of the Spirit redesign. I just think that if it's OSS, it should be public.

[...] Lately, I've used it to make proto-specific announcements that wouldn't be of general interest,

Again I'm not sure why you feel Proto-related announcements are not of general interest, provided if they include the usual [Proto] subject-tag, so people can filter out what's not of interest to them.

but I'd be fine with retiring it as a failed experiment.

I'm not saying it's a failure. Just that I feel the Boost community would be better served by not having lib-specific MLs, that's all. My +1 to retiring the proto-specific list :) --DD