Re: [boost] [review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30

Subject: Re: [boost] [review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-08-22 11:46:20

On 8/22/2014 9:43 AM, Niall Douglas wrote:
> On 22 Aug 2014 at 9:21, Edward Diener wrote:
>
>>>> OTOH if you choose to clone the library in your modularboost/libs/vmd
>>>> the top-level index.html link should work perfectly.
>>>
>>> That involves more work than I wish to do right now. Right now I
>>> merely wish to find out if I could contribute a meaningful review.
>>
>> The library is on Github and I am following the modular-boost format so
>> I do not know what else I can do to make it easy for others to use and
>> review the library. I do not think that asking reviewers to clone a
>> library and follow instructions in a readme file in order to use it, is
>> asking an awful lot of reviewers.
>
> Equally you want us to give you our time for free to look at your
> stuff. Some would say that putting the documentation onto its own
> website - like every other library in the review queue does by the
> way - isn't asking much of you. For you it's literally a git push to
> github pages and it saves all of us the hassle of cloning your repo
> and patching it into boost just to see if it's interesting at all to
> us.

How do you want me to present the documentation ? As a separate github 
project by itself, or as a separate branch of the VMD project ? I am 
willing to do either of those things.

I was not aware that every other library puts its documentation on its 
own website outside of GitHub. In that case it seems to me that it 
should have been a requirement of submitting a library to Boost or at 
least strongly suggested somewhere.

>
>>>>> However from what I read I ask this: why is this library useful?
>>>>
>>>> The introduction explains in general the functionality in the library
>>>> that would make it useful. Did you read the introduction ?
>>>
>>> Yes. I get what it does. Not why would anyone need this.
>>
>> It is a library for writing C++ macros, like Boost PP. If you do not see
>> any use for Boost PP then naturally you would not see any use for the
>> VMD library.
>
> I see a use for Boost PP in interfaces, mainly to emulate variadic
> templates in 03. With C++ 11 I see little use for Boost PP in
> interfaces, but I can see it might be handy to have occasionally in
> internal source code away from public interfaces.
>
> I struggle to see how variadic macros add to Boost PP in such a
> limited use case. This is the source of my difficulty.

The Boost TTI library ( I am the developer ) uses variadic macros in 
order to pass, among other things the name of the element to be 
introspected. Many other libraries use macros, and some variadic macros, 
as part of its interface. In my tests using Boost PP, since I work on 
fixes to it, there are about 45 other libraries that use Boost PP. There 
are a number of Boost libraries that use variadic macros in advanced 
cases. There are probably many end-users out there using variadic macros 
in their own programming.

I can understand that your focus is on C++11/C++14. It is pretty 
exciting as far as the things that can be done within the C++ language 
itself. But macro preprocessor programming still hold my interest obviously.

>
>>> The answer is no, but to enter Boost yes. It's very hard for me or I
>>> suspect anyone to vote on this if I have no idea what it's useful
>>> for. Otherwise someone could submit a randomly generated library and
>>> claim it should enter Boost, and we couldn't refuse.
>>
>> I can't make you see any use for the library other than writing the
>> documentation to explain how it is used and what it offers for macro
>> creation.
>
> It is you who wants the library to enter Boost. It is therefore you
> and only you who must argue in favour. We default to a reject answer,
> it is you who must persuade beyond a reasonable doubt to not reject.

I am not a politician and can only persuade based on my technical work 
and explanation of it.

>
>>> I get this is all very clever. And if this library were being
>>> proposed for a suite of C libraries, I'd be all over this like no
>>> tomorrow.

The macro preprocessor is just as much a part of C++ as of C. If you 
mean that you think that C++ has such advanced facilities over C ( to 
which I generally agree ) that it makes macro programming obsolete ( to 
which I do not agree ) then VMD has no use for you.

>>>
>>> I don't get how this is useful, or wise for C++ however. If you can
>>> show me something it can do which is a pain point for many which
>>> cannot be achieved using C++ 14, you get my vote. Otherwise I don't
>>> see the use case given the much superior alternatives.
>>
>> I do not know what the superior alternatives of C++ 14 are which you
>> see.
>
> Neither do I. I think it is up to you as the presenter of the library
> to tell me why your library is useful to me. I'm not going to decide
> if it's useful to me on my own. I don't have the time. I suspect
> neither do most people here.

The documentation explains its usefulness in macro programming.

>
>> I can only guess that you do not feel that the creation of macros
>> as part of the interface to a library should ever be necessary. But for
>> a number of Boost libraries they still are, and for future libraries
>> they still will be until C++ has built-in support for things which the
>> macro prerprocessor can still do.
>
> I think this is evading the question. You are equivocating here
> Edward.

I am not equivocating. You are asking a general question and I am giving 
you an answer as best I can.

I do understand that you may be criticizing the documentation for not 
presenting a strong enough use case for the functionality of the 
library, as part of the introduction/overview in the beginning of the 
documentation, and I will strongly take that criticism into account and 
look to update the documentation based on it.

>
> For reference, I do believe that in C++ 14 code there has to be a
> high bar set on the use of macros in public interfaces, especially as
> C++ 17 Modules will deprecate that. For that reason, macros in
> interfaces is a bad idea.

I do not understand the link between C++ 17 Modules and macro programming.

>
> But I'm giving you out here Edward: give me a use case where your
> library solves a hard problem for others which C++ 14 cannot and you
> get my yes vote because I trust you to have made a good technical
> solution, my problem is in why it is useful. I don't think I am being
> unreasonable or unfair here, if your library is useful we need to see
> proof.

I do not want an "out" because you trust I have made a good technical 
solution. I only want for anyone, including yourself, to determine 
whether they find the library useful enough, and as an extension to 
Boost PP functionality when doing macro programming, to decide whether 
or not it should be a Boost library, just as Boost PP is a Boost library.

If I have not made the point well enough of what other functionality VMD 
adds to macro programming on top of what is in Boost PP I am perfectly 
willing to update the eventual documentation. But I need particulars of 
what is not understood or what seems poorly documented.

>
> I equally don't mind if anybody else chimes in here with a concrete
> example of where this variadic macro library solved a real problem
> for them. I assume that if this library got a review manager, it must
> have solved something for somebody somewhere. Equally, if no one
> chimes in, I must assume that this library has not met the popularity
> test and therefore has not been suffiiciently tested in real world
> use. And that would affect my vote for obvious reasons.