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

Subject: Re: [boost] [yap] review part 3: tests + misc + summary
From: Brook Milligan (brook_at_[hidden])
Date: 2018-02-21 17:15:47

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