Re: [boost] Interest in updated expression template library?

Subject: Re: [boost] Interest in updated expression template library?
From: Brook Milligan (brook_at_[hidden])
Date: 2017-01-11 13:03:08

> On Jan 11, 2017, at 7:42 AM, Zach Laine <whatwasthataddress_at_[hidden]> wrote:
> 
> On Tue, Jan 10, 2017 at 8:50 PM, Brook Milligan <brook_at_[hidden]> wrote:
> 
>> 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.

OK, I get it now.  Your transforms are acting in much the same way that Proto contexts act.  They define the interpretation of the expression tree when explicitly passed to the evaluate() function.  Perhaps noting the connection (in a “comparison with / moving from Proto” section?) is worth noting, as I missed it at first.

It seems that the reference documentation for evaluate() does not note that the transform argument is optional.  Given your examples that call evaluate() with only a single argument, it seems to be optional.  Is that also true for evaluate_as()?  Should this be made explicit in the reference docs?

Thanks for the clarification.

Cheers,
Brook