
I've hit something that I find weird in the behaviour of transforms. I don't know what is the intention. Basically, what seem to be happening is that if a transform doesn't cover all the cases but a pattern matches at some external level, then that is taken as a match. For instance, given the following transform: struct width_transform : proto::or_ < terminal_width<proto::terminal< number<_> > >, binary_width<proto::binary_expr<proto::tag::plus, width_transform, width_transform> > > {}; and evaluating the transform for proto::binary_expr<proto::tag::minus, something, something>, I get binary_width "called". If I add a pattern for proto::binary_expr<_, width_transform, width_transform> then that pattern is used. I would expect a failure at compile time, but in any case adding a wider pattern after a narrower pattern should never change whether the former matches or not. Unless I'm making something stupid, in which case just let me know, I'm used to it. Best regards, Maurizio

Maurizio Vitale wrote:
I've hit something that I find weird in the behaviour of transforms. I don't know what is the intention.
Basically, what seem to be happening is that if a transform doesn't cover all the cases but a pattern matches at some external level, then that is taken as a match. For instance, given the following transform:
struct width_transform : proto::or_ < terminal_width<proto::terminal< number<_> > >, binary_width<proto::binary_expr<proto::tag::plus, width_transform, width_transform> > > {};
and evaluating the transform for proto::binary_expr<proto::tag::minus, something, something>, I get binary_width "called". If I add a pattern for proto::binary_expr<_, width_transform, width_transform> then that pattern is used.
I would expect a failure at compile time, but in any case adding a wider pattern after a narrower pattern should never change whether the former matches or not.
Unless I'm making something stupid, in which case just let me know, I'm used to it.
Yes, the assumption is that you will only be applying a transform to expressions that match the grammar. You can enforce this via: // make sure it matches BOOST_MPL_ASSERT((matches<Expr, width_transform>)); // apply the transform width_transform::call(expr, state, visitor); It would be nice if it failed loudly, instead of silently doing the wrong thing, though. I'll looking into changing this. -- Eric Niebler Boost Consulting www.boost-consulting.com

Thanks Eric, Eric Niebler <eric@boost-consulting.com> writes:
Yes, the assumption is that you will only be applying a transform to expressions that match the grammar. You can enforce this via:
// make sure it matches BOOST_MPL_ASSERT((matches<Expr, width_transform>)); // apply the transform width_transform::call(expr, state, visitor);
It would be nice if it failed loudly, instead of silently doing the wrong thing, though. I'll looking into changing this.
Would be very nice to have, if doable. Otherwise, should be spelled out very clearly in the documentation, in case it is not now. In my case there's one grammar passed to the domain, but then there're many others embedded in transforms and their structure is typically different. For instance, in the general grammar you typically have one pattern capturing all binary expressions, but then for specific transforms you may need to have more refined patterns and it is probably rather easy to forget to cover some parts of the space covered by the general grammar. Regards, Maurizio
participants (2)
-
Eric Niebler
-
Maurizio Vitale