On Tue, Jan 10, 2017 at 8:50 PM, Brook Milligan
On Jan 10, 2017, at 7:35 AM, Zach Laine
wrote: In the examples you will find nearly all of the Proto examples reproduced, each in a-bit-less to dramatically-less code. The only Proto examples that were left out were ones that are now trivial using Yap due to differences in design.
As I am sure you know, Proto makes use of a context class to define the meaning of the expression trees. As a consequence, the same expression tree can be given different meanings by evaluating it with different context types.
Right.
It seems that Yap defines the meaning in terms of a set of function overloads.
Yes and no. There are *implicit* transformations and evaluations that work based on extension points/function overloads; there can indeed only be one overload that gets selected, and this is implicitly chosen based on the normal overload resolution rules. There is also the explicit transform() function. This is what most of the examples use, and it is my preferred and recommended way of doing things. It allows you to define whatever transforms you like, including transforms that evaluate your expression in whole or in part. You can have as many of these as you like, and there is often no need to define a context per se. I say "per se" because the transform itself often looks much like a Proto context (e.g. it might be stateful). See the examples in the docs for details.
Is it possible to give Yap expressions different meanings in the same sense that Proto does or is a single meaning encapsulated in the overload set? If the latter, then it seems that this should be pointed out explicitly in the documentation. If the former, clarifying how to accomplish this would be helpful.
It is, as I said above. Something much like what I wrote above appears in the tutorial docs. Zach