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-25 20:39:40

On 8/25/2014 6:04 PM, Rodrigo Madera wrote:
> On Mon, Aug 25, 2014 at 3:12 PM, Edward Diener <eldiener_at_[hidden]>
> wrote:
>>
>> The problem of merging VMD into Boost PP is twofold.
>>
>> First Boost PP is still Paul Mensonides library and his philosophy of
>> safety, which I totally respect, is part of Boost PP.
>>
>> Secondly, as you have already said and realize, the philosophy of VMD is
>> that preprocessing errors can occur if the functionality in VMD is misused
>> by a programmer. In other words VMD depends on the constraints discussed in
>> the library to work correctly. But within those constraints it does work
>> and adds a great deal of flexibility to macro metaprogramming and the
>> design of macro input.
>
>
> Could you please provide a link to this mentioned safety philosophy of
> Boost PP?

There is no link I can give, other than to say it is my interpretation 
of the philosophy of Boost PP from looking at code and working/talking 
privately with Paul.

I do not believe that passing incorrrect data to Boost PP functionality 
will ever produce a preprocessing error. It may produce an undefined 
result but that is then the programmer's problem misusing some 
functionality of Boost PP.

Another example of the "safety philosophy" of Boost PP is that Paul was 
well aware that he had written a better variadic macro to test for 
emptiness, as well as that the Boost PP library has an undocumented 
non-variadic test for emptiness used internally. He did not want the 
current non-variadic version to be documented and he made no move to add 
the variadic version to Boost PP.

In general he has always been very careful to not introduce any 
functionality in Boost PP that could produce incorrect results when used 
"correctly", as well as being very careful not to introduce 
functionality into Boost PP which could cause programmers to misuse the 
library by making anything more complicated than he felt it need be.

This is what I mean by his "philosophy of safety".

>
> As far as I can tell, Boost PP will give strange results if you don't obey
> its design constraints. I.e., try to use a malformed tuple.

But it does not create a preprocesing error AFAIK. It basically is 
telling you that passing the wrong sort of data gives you undefined 
results and that the undefined results are not any of the expected results.

> Is Boost PP
> using some kind of protection that VMD isn't?

No, VMD is simply designed in a number of cases without any protection 
if you feed it something it cannot handle, simply because there is no 
way you can use the preprocessor to pre-detect the sort of thing which 
could give a preprocessor error. This is not always the case and VMD 
does the best job it can to detect invalid input and act accordingly. 
But VMD accepts, because of the extended functionality it offers, that 
some incorrect input can give a preprocessing error. This is part of 
what I talk about in the documentation when I mention input "constraints".

The defacto example of this in VMD is parsing/identifying a number or 
identifier. In order to do this it uses preprocessor concatenation ( the 
'##' symbol ). For this to work in VMD the preprocessor token being 
tested must not begin with anything which is not an alphanumeric, 
underscore, or the left parenthesis of a tuple ( all of which in the VMD 
docs resolves to what is called "vtype" preprocessing data ). VMD cannot 
catch an error if you attempt to identify as a number or an identifier a 
preprocessor sequence of tokens starting with "&aname" let us say. It is 
just impossible to do. But the functionality is still there because VMD 
takes the philosophy that the macro creator using VMD has set as a 
constraint for the user of a macro that the input being tested is what 
VMD can handle correctly for a particular use of its functionality. If 
the end-user does not follow the "constraint" of a macro designer for 
some type of input, and therefore a compiler preprocessor error is 
unavoidably produced, it is the end-user's fault in the opinion of VMD.

So if you have some input like "&aname" you can certainly use it as is 
in your macro programming but you can't pass it to anything in VMD 
expecting it is one of the v-types which VMD understands.

That's what I mean by VMD being different than Boost PP. VMD pushes  the 
bounds of what you can do in the preprocessor, using variadic macro 
techniques, with the knowledge that incorrect input to its functionality 
will sometimes just stop the preprocessor with an error. Boost PP never 
does this AFAIK, in the interests of safety. Both have their place but 
to me they are two different libraries.