Re: [boost] Yap's formal review is starting now!

Subject: Re: [boost] Yap's formal review is starting now!
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-02-14 22:34:50

On 2/14/2018 4:00 PM, Zach Laine via Boost wrote:
> On Tue, Feb 13, 2018 at 7:07 PM, a.hagen-zanker--- via Boost <
> boost_at_[hidden]> wrote:
> 
>>> We encourage your participation in this review. At a minimum, please
>> state:
> 
> 
> Thanks for reviewing, Alex.
> 
> 
>> * Boost YAP review notes
>>
>> The documentation could be a lot more accessible. First of all it would be
>> good if you could limit the references to Proto, this is not helpful for
>> users who don't know Proto. Perhaps one separate page where you list the
>> difference between Proto and Yap would be useful.
> 
> 
> Yeah, I'm getting the impression you're not alone in not having used
> Proto.  I'll do exactly as you suggest here.  *TODO*
> 
> 
>> Next, remove all the jokes. Some are funny and others not, but none are
>> helpful. And when trying to get my head around how to use the library, it
>> is annoying to read the same joke again-and-again. (Yes, it took me many
>> reads to understand what the library is offering exactly). The bloggy
>> casual style is annoying me, when I am trying hard to make sense of the
>> library.
>>
> 
> Well, I'm a pretty casual person.
> 
> 
>> Don't use examples without explaining what they are an example of.
>>
> 
> Could you give an example?  No snark, I just don't know exactly what you're
> referring to here.
> 
> 
>> It would be good if the documentation page could include a definition /
>> explanation of what an expression template is.
> 
> 
> Agreed.
> 
> 
>> Actually, I think you need to define what an expression is in this
>> context. In my book, expressions are not just made of operators, but can
>> also include function calls. However, the implicit impression I get from
>> the YAP documentation is that you only consider expressions based on
>> operators, and not functions. For instance, I consider std::sqrt(x) an
>> expression. However, looking at expr_kind (https://tzlaine.github.io/
>> yap/doc/html/boost/yap/expr_kind.html) it seems that this kind expression
>> is not supported, (but it could be as a Transform).
>>
> 
> That's supported.  std::sqrt(x) would need to be Yap-ified if x is not
> already Yap expression, perhaps by making a sqrt Yap terminal, or by
> calling std::sqrt on a Yap expression.  Assuming x is a Yap expression, the
> entire expression "std::sqrt(x)" is a Yap expression whose kind is
> expr_kind::call.  This underscores the need to make this more explicit in
> the docs, though. *TODO*
> 
> 
>> *Section Compiler Support
>> I don't think it is acceptable to produce a library that cannot be
>> compiled in MSVC own front-end.I can see that Hana got away with it on the
>> premise of being ground-breaking and pushing the boundaries. However, YAP
>> is not trying to be groundbreaking, it is offering stuff that Proto already
>> offered and generalizing functionality of Eigen, UBLAS and others.
> 
> 
> Yap's feature set is essentially a superset of Proto's, but with reasonable
> compile times. That is something that no library has done before.  This is
> literally the definition of groundbreaking.  But I take your point.  You
> want MSVC support.
> 
> 
>> Can you really not support MSVC? What is the bottleneck, and did you try
>> to work around it?
>>
> 
> MSVC does not have a conforming C++14 compiler.  Its constexpr support is
> quite bad.  Louis Dionne has mentioned that the MSVC team is explicitly
> trying to get Hana working as part of its recent development efforts.
> Hopefully such changes land soon.  I'm not terribly interested in
> undertaking herculean efforts to make a constexpr-friendly and
> metaprogramming-heavy library work on a constexpr- and
> metaporgramming-unfriendly compiler.  Some Boost libraries do that and some
> do not, and this has been the case for years.

MSVC is the big gorilla in the room. Because of that many man-hours have 
been spent by many Boost developers getting code to work with MSVC. I 
can tell you with certainty that because of its non-standard 
preprocessor it took many times the amount of work getting variadic 
macros in Boost PP to work with MSVC and getting VMD to work with MSVC 
than all the other work put together in those areas.

With that said I want to support your decision not to have to make 
"herculean efforts", as you say, to get MSVC to work with your library. 
It's long past time when MSVC should try to get their compiler to 
support C++ correctly, and this goes not only for their preprocessor, 
but also for their support of the latest C++ standards. Boost libraries, 
which should be targeting standards, are one of the best pieces of 
software to get companies like Microsoft ( hardly the only perpetrator ) 
to create a C++ compiler which follows the standard.

snip...

> 
> Zach