Re: [boost] [contract] syntax redesign

Subject: Re: [boost] [contract] syntax redesign
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-23 13:50:08

on Sat Oct 22 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:

> On Fri, Sep 2, 2011 at 3:14 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Fri Sep 02 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
>
>>> (I still have to implement named parameter support (using
>>> Boost.Parameter behind the scene) but that shouldn't be too hard. The
>>> macros already parse the named parameter syntax using in/out/inout
>>> "keywords".)
>>
>> I can't wait.
>
> Hello all,
>
> Here's how I am thinking to support named parameters within
> Boost.Contract's syntax. 

Cool!  Don't forget deduced parameters, though ;-)

> Essentially, named (also template) parameters are prefixed by the new
> preprocessor "keywords" in, out, or in out.
>
> Sorry for the large amount of code but these are complex examples from
> Boost.Parameter docs so you can directly compare this Boost.Contract
> proposed syntax with the one of Boost.Parameter:
> http://www.boost.org/doc/libs/1_47_0/libs/parameter/doc/html/index.html
>
> namespace graphs {
>
> BOOST_PARAMETER_NAME(graph)
> BOOST_PARAMETER_NAME(visitor)
> BOOST_PARAMETER_NAME(root_vertex)
> BOOST_PARAMETER_NAME(index_map)
> BOOST_PARAMETER_NAME(color_map)
>
> CONTRACT_FUNCTION(
> void (depth_first_search) (
>         namespace tag, // optional namespace (tag assumed by default)

I'd really like to eliminate that if possible; it's quite off-putting.
I guess if you can make it optional, that handles the problem.

>         in requires( // requires for type requirements

Why are we using "in" before "requires?"  Requirements are not "in parameters."

>             boost::mpl::and_< boost::is_convertible<
>         boost::graph_traits<boost::mpl::_>::traversal_category ,
>         boost::indicence_grapth_tag
>                   >
>                 , boost::is_convertible<
>                       boost::graph_traits<boost::mpl::_>::traversal_category
>                     , boost::vertex_list_graph_tag
>                   >
>             >

I realize this is a direct translation of what's in the Boost.Parameter
docs, but it would be instructive to see the example without all the
mess, using something like concepts for the "requires" clause.  In fact,
I believe much of what you have below could also be consolidated into
something more semantically meaningful.  Would
something like that be possible?  Also, the use of graphs::graph::_ and
boost::mpl::_ below is confusing me.  I've never heard of the former.  

I guess, to sum up, to evaluate the syntax I'd need to see the most
beautiful possible realization of this algorithm as opposed to the most
horrendous ;-).

> And for class templates:
>
> namespace py {
>
> BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType)
> BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList)
> BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType)
> BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable)
>
> CONTRACT_CLASS(
> template(
>     in typename ClassType,
>     in typename BaseList, default boost::python::bases<>,
>     in typename HeldType, default ValueType,
>     in typename Copyable, default void
> )
> class (class_) requires(...) // concepts
> ) {
>     ... // class invariants, members with pre/postconditions, etc
> };
>
> } // namespace py
>
> struct b { virtual ~b() = 0; }
> struct d : b { ~d(); }
>
> typedef py::class_<b, boost::noncopyalbe> c1;
> typedef py::class_< d, std::auto_ptr<d>, boost::python::bases<b> > c2;

This one, again, uses deduced parameters, because as I'm sure you
noticed, boost::noncopyable doesn't play the same role as
std::auto_ptr<d>.  I presume that's possible in your scheme.

> IF I can do this (not sure yet), it should be beneficial especially
> for class templates because all the boiler plate code (class template
> skeleton A0, A1 = parameter::void_, class template signature, argument
> pack, and parameter extraction) will be automatically generated by the
> CONTRACT_CLASS macro.
>
> Before I start diving into the implementation, what do you think of
> this syntax for named parameters?

Certainly looks nice for the class template case, but as noted above I'm
having a hard time digesting the function template example.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com