Re: [boost] [local] Review

Subject: Re: [boost] [local] Review
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-11-19 05:08:56

On Fri, Nov 18, 2011 at 11:23 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 11/19/2011 11:44 AM, Lorenzo Caminiti wrote:
>> On Fri, Nov 18, 2011 at 10:19 PM, Joel de Guzman
>> <joel_at_[hidden]> wrote:
>>> On 11/19/2011 6:44 AM, Lorenzo Caminiti wrote:
>>>>> As boost is trying to not only push the boundaries of C++ it should also try
>>>>>> to set examples of best C++ practice. I would not consider Macro calls to
>>>>>> interface with a library not good practice.
>>>> I understand. I disagree but I understand your point. I disagree
>>>> because the use of macros in this context saves the user from writing
>>>> verbose boiler-plate code.
>>>>
>>>> IMO, it is similar to Boost.ScopeExit: Instead of providing the
>>>> SCOPE_EXIT macros we could have said that the user writes the code to
>>>> bind the variables deducing their types and it programs the local
>>>> class with the exit code in the desstructor all of that by hand.
>>>> However, using macros saves the user to write all of that and as I
>>>> user I personally appreciate that. It is true that there is a trade
>>>> off between the readability cost of using macros and the benefit of
>>>> not having to write boiler-plate code. I find that trade off
>>>> acceptable for libraries like Boost.SopeExit or even ForEach and (of
>>>> course ;) ) also for my library so I don't have to write the
>>>> boiler-plate code for the binding and the casting to pass the local
>>>> class as a template parameter.
>>>
>>> I share Thomas' sentiment. But IMO, it's really not about using macros.
>>> it's about the syntax. Boost.Foreach looks exactly like a for loop.
>>> The proposed boost locals syntax is arcane. IMO, bottomline: it's
>>> about the design of the DSEL regardless how it is implemented. And,
>>> the syntax proposed is, well, utterly ugly. Anything more complex than
>>> foreach, done using the PP will be a mess. An ugly syntax can be acceptable
>>
>> That is fine but the definition of "ugly" is subjective so IMO it
>> should be left up to the reviewers (and Thomas' point is clear, the
>> syntax is ugly for him as one of the reviewers).
>>
>>> IFF there is no other way to do it. In this case (locals), there are
>>> better ways of doing the same thing.
>>
>> But there is no other way to do locals allowing to use statement
>> syntax for the function definition.
>
> Why can't we C++ programmers just accept the fact that we don't
> have *true* local functions like those in Pascal and Modula?

Because now we have Boost.Local so we can program true local functions
with all their functionality :) (If not, which local function
functionality is missing from Boost.Local?)

> Challenge: try to port one moderately sized Pascal code (I
> suggest a recursive descent calculator parser) using your
> proposed library. I know the result will be utterly ugly and
> unreadable compared to the real thing, but let the readers be
> the judge.

Sure, after the review I'll program such an example and add it to the
Examples section
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Examples.html
BTW, do you have some code (possibly Pascal) to start from? Do you
have such a code programmed in Phoenix already?

> I can write the same using non-local functions and/or offline
> function objects using only straight C++. The result will be
> very readable. Not as elegant as the one using Modula's local
> functions, but certainly better than using your proposed locals
> library. That is what I mean by "better ways of doing the same
> thing".

Well, we'll have to wait and see the code example to judge. Please
note that had this request come ~1year ago when I started collecting
feedback, I'd be happy to program the example just using the proposed
library syntax even before starting to implementing it. Too bad no one
thought about it back then... but it's never too late.

To the end of exercising my library, I did program /all/ the examples
I found from the references I looked at (N2511:
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Bibliography.html
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Examples.html

Including the examples from GCC extension nested functions:
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Examples.html#boost_local.Examples.gcc_nested_functions

But these are short examples.

> Again, I share Thomas' sentiment. It's not worth the additional
> complexity and arcane syntax. There are two scenarios here:

What do you mean by "complexity" here? As for the syntax, with respect
the the normal C++ syntax:

// some local scope
int f(int x) {
    ... // lots of instructions here
}

It requires you to do two things:
1) Wrap the function name and parameter list in two macros.
2) And, move the function name after the function body.

// some local scope
int PARAMS(int x) {
    ... // lots of instructions here
} NAME(f)

To me and others this does not look arcane but I understand this is a
subjective.

BTW, why would you consider the above syntax arcane and the one below
"nice"? (I am honestly asking such a question, it is not that people
cannot change their minds, there would be no improvement otherwise,
but if that is the case I would sincerely like to know what prompted
such a change.)

-- from: http://lists.boost.org/Archives/boost/2011/02/176638.php --
On Fri, Feb 4, 2011 at 5:43 PM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 2/5/11 6:03 AM, Alexander Nasonov wrote:
>
>>> As far is a am concerned, I still find this syntax overly verbose.
>>> I do realize though that this is just a toy example. For better
>>> comparison,
>>> Here is how the same thing would like in Boost.Phoenix:
>>
>> Steven and I were playing with different syntaxes few years ago
>>
>> We came up with something like this:
>>
>>     void BOOST_LOCAL_FUNCTION
>>         ( BOOST_BIND((factor)(&sum)), double num )
>>     {
>>         sum += factor * num;
>>         std::clog<<   "Summed:"<<   sum<<   std::endl;
>>     }
>>     BOOST_LOCAL_FUNCTION_DECL(add)
>>
>> http://thread.gmane.org/gmane.comp.lib.boost.devel/168612/focus=168694
>
> That is nice!
-- end --

> 1) simple local functions --for those, you don't want the
> complexity of using a macro DSEL, just use plain functions and
> function objects. 2) Moderate to complex programs --for those,
> the macro syntax will get in the way of clarity of code -- for
> those, just use plain functions and function objects.

IMO, what is moderate or complex programs and which tool to use to
program them (Boost.Local, Phoenix, Lambda, etc) is a decision that
should be left to our library users.

> And I am not even mentioning c++ lambda. You can nitpick all
> you want, but it's still nitpicking. Nitpicks are not valid
> rationale for justifying a library for boost.

I am sorry but I don't understand this. Can you please re-word it?

Thanks a lot.
--Lorenzo