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@lists.boost.org> 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