Re: [boost] [contract] syntax redesign

Subject: Re: [boost] [contract] syntax redesign
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-06-02 09:28:57

Matt Calabrese wrote:
> 
> On Tue, May 31, 2011 at 2:49 PM, Lorenzo Caminiti
> <lorcaminiti_at_[hidden]>wrote:
>>
>> For example, I _think_ (but I've not implemented this yet) that I can
>> simplify the syntax like this:
>>
> 
> Looks good, I use pretty much exactly the same syntax in my library
> concerning parameter lists and templates (
> https://github.com/boostcon/2011_presentations/raw/master/thu/Boost.Generic.pdf
> slides
> 79 and 96 are okay examples). The only thing I'm confused about is how you
> 

Hey Matt, I am still looking over your slides so sorry in advance if the
following suggestions don't make sense... Is it possible remove some of the
extra parenthesis from your examples on page 79 and 96 as I suggest below?
If not, why?

// Legend:
// * Parenthesis `(token)` (no spaces around single token) are to wrap a
single
//   token within extra parenthesis.
// * Parenthesis `( token1 [, token2, ...] )` (spaces around token list) are
to
//   specify a list of tokens.

// Page 79 //

// N2914 syntax:
concept Iterator<typename X> : Semiregular<X> {
    MoveConstructible reference = typename X::reference;
    MoveConstructible postincrement_result;
    requires HasDereference<postincrement_result>;
    reference operator*(X&);
    reference operator*(X&&);
    X& operator++(X&);
    postincrement_result operator++(X&, int);
}

// Boost.Generic syntax:
BOOST_GENERIC_CONCEPT
( (Iterator)( (typename) X ), ( public Semiregular<X> )
, ( (MoveConstructible) reference, typename X::reference )
, ( (MoveConstructible) postincrement_result )
, ( requires HasDereference<postincrement_result> )
, ( (reference)(operator dereference)( (X&) ) )
, ( (reference)(operator dereference)( (X&&) ) )
, ( (X&)(operator preincrement)( (X&) ) )
, ( (postincrement_result)(operator postincrement)( (X&), (int) ) )
)

// Is the following syntax possible?
BOOST_GENERIC(
// Use leading `concept` "keyword" to determine macro functionality.
// `typename` doesn't need extra parenthesis.
// `extends` is not necessary but I find it more readable.
concept (Iterator)( typename X ) extends( public Semiregular<X> )
    // Extra parenthesis after comma `, ( ... )` are not necessary.
    // BOOST_GENERIC_ASSIGN just expand to `,` but I find it more readable.
    , (MoveConstructible) reference BOOST_GENERIC_ASSIGN typename
x::reference
    , (MoveConstructible) postincrement_result
    , requires HasDereference<postincrement_result>
    // `operator(symbol, name)` allow user to name the operators (name is
any
    // arbitrary alphanumeric token) so no predefined operator name to
learn.
    // Types `X&`, `X&&`, `int`, etc do not need extra parenthesis.
    , (reference) operator(*, deref)( X& )
    , (reference) operator(*, deref)( X&& )
    , (X&) operator(++, preinc)( X& )
    , (postincrement_result) operator(++, postinc)( X&, int )
)

// Page 96 //

// N2914 syntax:
template<ObjectType T> concept_map RandomAccessIterator&lt;T*&gt; {
    typedef T value_type;
    typedef ptrdiff_t difference_type;
    typedef T& reference;
    typedef T* pointer;
}

// Boost.Generic syntax:
BOOST_GENERIC_CONCEPT_MAP
( ( template ( (class) T ) ), (RandomAccessIterator)(T*)
, ( typedef T value_type )
, ( typedef ptrdiff_t difference_type )
, ( typedef T& reference )
, ( typedef T* pointer )
)

// Is the following syntax possible?
BOOST_GENERIC(
// Use `concept_map` "keyword" to determine macro functionality.
// Do you need ObjectType? Is was missing from above syntax...
template( (ObjectType) T ) concept_map (RandomAccessIterator)( T* )
    , typedef T value_type
    , typedef ptrdiff_t difference_type
    , typedef T& reference
    , typedef T* pointer
)

--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/contract-syntax-redesign-tp3563993p3568343.html
Sent from the Boost - Dev mailing list archive at Nabble.com.