Re: [boost] [yap] review part 3: tests + misc + summary

On Wed, Feb 21, 2018 at 11:15 AM, Brook Milligan via Boost < boost@lists.boost.org> wrote:

On Feb 21, 2018, at 9:28 AM, Steven Watanabe via Boost wrote:

What does evaluate_with_context now do? Let's say expr is "a + b". Does the context only apply to the evaluation of a and b as terminals, or does it apply to the plus operation as well?

It applies to the plus operation first. If the context has a handler for plus, then it's up to the context to handle recursion. If it does not, then it becomes evaluate_with_context(a, ctx, x...) + evaluate_with_context(b, ctx, x...)

Are such applications of the context conditional? How does the reader quickly grasp what the evaluate_with_context() call does? This seems like really muddy code to me. If you have something else in mind, please provide more detail -- I may of course be misunderstanding you.

My idea is that it would behave exactly like transform, except that the default behavior for nodes that are not handled by the context is to evaluate the operators instead of building a new expression.

For the record, this is exactly what I had in mind when I was originally suggesting evaluate_with_context(). It seems to me that this does not introduce new surprises or require "code spelunking". As it is, to understand the meaning of evaluate(), one might have to wander all over a code base to find all the relevant definitions. Perhaps this is fine for well-understood types, but it does not lend itself to types with no natural operator definitions, for which operators might be better _not_ defined. In such cases, it might actually be easier to just look at a single "context" class for overloads. It is certainly not a surprising place to look if the documentation for evaluate_with_context() specifies something like what Steven wrote above. Furthermore, it would mean that certain types of grammars that are not tightly tied to naturally defined C++ operators (Steven's mention of Spirit is apt here) could be written much more easily (and with more type safety) by providing different context classes (perhaps Qi v. Karma is relevant) for different calls to evaluate_with_context(). I still feel that this is a valid use case that should be supported.

I agree. I've added this to the GitHub issues list. I'm probably going to call it transform_evaluate(), which is closer to what it does IMO than evaluate_with_context(). I truly did not understand that this was what you meant. Zach