I am trying to use Boost.Proto with some user-defined function terminals. Following the documentation, this requires specialization of context::eval classes to handle new terminals. (Using the callable_context<> mechanism is too simplistic because that seems to require a uniform result_type.) However, doing as suggested (see the "Defining an Evaluation Context" section) does not compile when function terminals are involved. My solution is a new traits class that deduces the type of a terminal. This does allow successful specialization of context::eval on the type of terminal, even with functions. To illustrate this, I have attached a set of three files, one implementing an example proto function, one implementing the relevant metafunction, and one demonstrating both use cases: the one corresponding to the Boost.Proto documentation and the one corresponding to my alternative. I would appreciate comments on the following: - Is this a valid problem and a valid solution or have I missed a standard method using Boost.Proto that works to solve this pattern? - Is this the standard way of creating function terminals in Boost.Proto or have I done something there to trigger the problem? - If the answer to these questions indicates a missing feature within Boost.Proto, what is the process for fixing that? Thanks for any help you can offer. Cheers, Brook