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.
Cheers,
Brook
