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

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
meant.

Zach