Boost logo

Boost :

Subject: Re: [boost] [yap] review part 3: tests + misc + summary
From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2018-02-21 21:45:40

On Wed, Feb 21, 2018 at 11:15 AM, Brook Milligan via Boost <
boost_at_[hidden]> wrote:

> On Feb 21, 2018, at 9:28 AM, Steven Watanabe via Boost
> <boost_at_[hidden]> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at