On Jan 11, 2017, at 4:34 PM, Brook Milligan
wrote: Now at least I can give it a try. Thanks again for the help.
OK, now that I’m trying it, I have another suggestion. Please include your “customization points” code as an example file in the codebase. I started with that and noted that your “make_terminal(user::number({2.0})” bits are missing a template parameter for the expression. I used boost::yap::expression, which seems to work fine. That might be confusing for some users. This brings up some questions. I recall you stating in the docs that boost::yap::expression<> should be used only for prototyping. The Expression concept is really simple and seems mostly to be a type placeholder for overload resolution. Is that fair? If one is not “supposed” to use boost::yap::expression<>, are there any design considerations / best practices for making a custom expression type? For example, it would seem that a common idiom might be an expression class with a function call operator for evaluation. Does that make sense? Are there general features that useful expression classes “ought” to have or at least should be considered in their design? Or are they really just the bare bones of the concept itself? Can you give some guidelines regarding best practices for all of this? Generally, I feel the documentation is good for a basic understanding and the examples illustrate some very simple use cases. But for anyone wishing to use Yap more deeply, a great deal of extrapolation from those cases will be necessary. It would be really helpful to encapsulate more use cases, common idioms, or best practices in the reference documentation so that practitioners can make more effective use of the library. Thanks again. Cheers, Brook