[Review] Proto review starts today, March 1st
Hi all, The review of Eric Nieblers Proto library starts today, March 1st 2008, and will end on March 14th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: Proto is a framework for building Domain Specific Embedded Languages in C++. It provides tools for constructing, type-checking, transforming and executing expression templates. More specifically, Proto provides: * An expression tree data structure. * Operator overloads for building the tree from an expression. * Utilities for defining the grammar to which an expression must conform. * An extensible mechanism for immediately executing an expression template. * An extensible set of tree transformations to apply to expression trees. * A mechanism for giving expressions additional behaviors and members. Documentation is here: http://boost-sandbox.sourceforge.net/libs/proto Download proto.zip from here: http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapro gramming Proto is a very important infrastructure library, IHMO. It has been used as the backbone for several other library writing efforts already, such as Xpressive and the rewrite of Spirit (there it has been used for all three parts: the parser, the lexer and the generator modules), and it is a key enabling technology in the long-planned unification of Phoenix and the Lambda Library. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager
Hello,
First of all, sorry for the long post.
I'm doing a Locally Unique Identifier generator library.
The DSL grammar is quite complex (see below), so the use of optional
parameters seams unavoidable. I have started to use the Boost.Parameter
Library as the Boost.Flyweight does.
For the recover node which can takes two optional parameters recovery_when
and recovery_how, this results in:
<code>
template <typename Arg1=parameter::void_, typename Arg2=parameter::void_>
struct recover : on_release_marker {
private:
typedef parameter::parameters<
parameter::optional<
parameter::deduced<recovery_when<> >,
is_recovery_when<boost::mpl::_>
>,
parameter::optional<
parameter::deduced<recovery_how<> >,
is_recovery_how<boost::mpl::_>
>
> signature;
typedef typename signature::bind<Arg1,Arg2>::type args;
public:
typedef typename parameter::binding<
args,recovery_when<>,dsl::immediate<>
>::type recovery_when;
typedef typename parameter::binding<
args,recovery_how<>,dsl::fifo<>
>::type recovery_how;
private:
typedef parameter::parameters<
parameter::optional<
parameter::deduced<
detail::unmatched_arg
>,
mpl::not_<
mpl::or_<
is_recovery_when<boost::mpl::_>,
is_recovery_how<boost::mpl::_>
>
>
>
> unmatched_signature;
typedef typename unmatched_signature::bind<
Arg1,Arg2
>::type unmatched_args;
typedef typename parameter::binding<
unmatched_args,detail::unmatched_arg,
detail::unmatched_arg
>::type unmatched_arg_detected;
/* You have passed a type in the specification of a recover type that
* could not be interpreted as a valid argument.
*/
BOOST_STATIC_ASSERT((
is_same<unmatched_arg_detected,detail::unmatched_arg>::value));
};
</code>
There is a lot of syntactic boilerplate in the recover class which will be
repeated for each one of the & nodes on the DSL grammar.
I have defined a expr class which hides all this repetitive stuff. The
recover
class can then be defined as:
<code>
template <typename Arg1=parameter::void_, typename Arg2=parameter::void_>
struct recover : on_release_marker,
boost::dsl::expr<recover<>, mpl::vector<
boost::dsl::optional<recovery_when<>, is_recovery_when<mpl::_>,
immediate<> >,
boost::dsl::optional<recovery_how<>, is_recovery_how<mpl::_>, fifo<> >
>, mpl::vector<Arg1, Arg2> >
{};
</code>
I would like to know if there is an interest in such a expression, and if it
is the case if this could be added to the parameters library.
As the issue here is to transform an DSL expression to another DSL I
was wondering if the Boost.Proto which is now been review could help
to do this kind of transformations.
The expr.hpp file is attached. The class in not yet able to manage with a
variable number of parameters (up to 3). I would like to know if there
is a way to avoid preprocessor programming.
I have faced some problems when trying to avoid preprocessor programming.
The first one was doing the mapping from a vector of args to the
parameter::parameters::bind.
<code>
template <typename Signature, typename Args>
struct args;
template <typename Signature, typename Arg0>
struct args<Signature, mpl::vector<Arg0> > {
typedef typename Signature::template bind<Arg0>::type type;
};
template <typename Signature, typename Arg0, typename Arg1>
struct args<Signature, mpl::vector<Arg0, Arg1> > {
typedef typename Signature::template bind<Arg0, Arg1>::type type;
};
</code>
I don't know if there is a better way to do that, any hint is welcome.
Any way I think that it will be easier to adapt the
parameter::parameters::bind template to take a mpl sequence.
See the definition of bind in boost/parameter/parameters.hpp
<code>
template <
BOOST_PP_ENUM_BINARY_PARAMS(
BOOST_PARAMETER_MAX_ARITY, class A, = void_ BOOST_PP_INTERCEPT
)
>
struct bind
{
typedef typename aux::make_arg_list<
typename BOOST_PARAMETER_build_arg_list(
BOOST_PARAMETER_MAX_ARITY, aux::make_items, PS, A
)::type
, deduced_list
, aux::tag_template_keyword_arg
>::type result;
typedef typename mpl::first<result>::type type;
};
</code>
The second problem concern the mapping from a vector to a
unmatched_signature, which is reduced to transform a mpl::vector to a
mpl::or_
<code>
template <typename Param0,typename Param1>
struct unmatched_signature<mpl::vector<Param0, Param1> >{
typedef parameter::parameters<
parameter::optional<
parameter::deduced<
detail::unmatched_arg
>,
mpl::not_<
mpl::or_<
typename Param0::pred,
typename Param1::pred
>
>
>
> type;
};
</code>
Is there something in boost that can simplify this mapping?
Best Regards
_______________________________________________
Vicente Juan Botet Escriba
_______________________________________________
LUID DSL grammar
_______________
luidg(
numeric_type(uint_type) ?
& on_overflow(
throw_on_error
| errno_on_error
| ignore_error
| user_error(user_function)
) ?
& on_release(
discard
| recover(
recover_when?
& recover_how?
)
) ?
& scope(
mono_threaded
| multi_threaded(locking? )
| multi_process(locking? )
) ?
& persistecy(
process(
void_pointer_type?
& allocator_type?
)
| kernel(
void_pointer_type?
& allocator_type?
& segment_manager_type?
)
| filesystem(
void_pointer_type?
& allocator_type?
& segment_manager_type?
)
) ?
& optimization (
speed
| space
) ?
& coherency (
ensure(bitset | set | ...)?
| ignore
) ?
)
recover_when (
immediate
| freeze
| delay(time_traits)
)
recover_how (
fifo
| undefined
)
locking(
internally(locking_traits)
| externally(mutex_type)
)
locking_traits (
thread_locking_traits
| process_locking_traits
| thread_recursive_locking_traits
| process_recursive_locking_traits
| ...
)
time_traits (
posix_time_traits
| ...
I am really sorry, I sent my previous mail as answer to the Proto review. I
wanted to send it a request for interest :-(.
---------------------------
Vicente Juan Botet Escriba
----- Original Message -----
From: "vicente.botet" <vicente.botet@wanadoo.fr>
To: <boost@lists.boost.org>
Sent: Sunday, March 02, 2008 8:39 PM
Subject: Re: [boost] [Parameter] is there an interest in this
templateparameter expresion
>
> Hello,
> First of all, sorry for the long post.
>
> I'm doing a Locally Unique Identifier generator library.
> The DSL grammar is quite complex (see below), so the use of optional
> parameters seams unavoidable. I have started to use the Boost.Parameter
> Library as the Boost.Flyweight does.
>
> For the recover node which can takes two optional parameters recovery_when
> and recovery_how, this results in:
>
> <code>
> template <typename Arg1=parameter::void_, typename Arg2=parameter::void_>
> struct recover : on_release_marker {
> private:
> typedef parameter::parameters<
> parameter::optional<
> parameter::deduced<recovery_when<> >,
> is_recovery_when<boost::mpl::_>
> >,
> parameter::optional<
> parameter::deduced<recovery_how<> >,
> is_recovery_how<boost::mpl::_>
> >
> > signature;
> typedef typename signature::bind<Arg1,Arg2>::type args;
> public:
> typedef typename parameter::binding<
> args,recovery_when<>,dsl::immediate<>
> >::type recovery_when;
>
> typedef typename parameter::binding<
> args,recovery_how<>,dsl::fifo<>
> >::type recovery_how;
> private:
> typedef parameter::parameters<
> parameter::optional<
> parameter::deduced<
> detail::unmatched_arg
> >,
> mpl::not_<
> mpl::or_<
> is_recovery_when<boost::mpl::_>,
> is_recovery_how<boost::mpl::_>
> >
> >
> >
> > unmatched_signature;
> typedef typename unmatched_signature::bind<
> Arg1,Arg2
> >::type unmatched_args;
> typedef typename parameter::binding<
> unmatched_args,detail::unmatched_arg,
> detail::unmatched_arg
> >::type unmatched_arg_detected;
> /* You have passed a type in the specification of a recover type that
> * could not be interpreted as a valid argument.
> */
> BOOST_STATIC_ASSERT((
> is_same<unmatched_arg_detected,detail::unmatched_arg>::value));
> };
> </code>
> There is a lot of syntactic boilerplate in the recover class which will be
> repeated for each one of the & nodes on the DSL grammar.
> I have defined a expr class which hides all this repetitive stuff. The
> recover
> class can then be defined as:
> <code>
> template <typename Arg1=parameter::void_, typename Arg2=parameter::void_>
> struct recover : on_release_marker,
> boost::dsl::expr<recover<>, mpl::vector<
> boost::dsl::optional<recovery_when<>, is_recovery_when<mpl::_>,
> immediate<> >,
> boost::dsl::optional<recovery_how<>, is_recovery_how<mpl::_>, fifo<>
> >
> >, mpl::vector<Arg1, Arg2> >
> {};
> </code>
> I would like to know if there is an interest in such a expression, and if
> it
> is the case if this could be added to the parameters library.
> As the issue here is to transform an DSL expression to another DSL I
> was wondering if the Boost.Proto which is now been review could help
> to do this kind of transformations.
> The expr.hpp file is attached. The class in not yet able to manage with a
> variable number of parameters (up to 3). I would like to know if there
> is a way to avoid preprocessor programming.
>
> I have faced some problems when trying to avoid preprocessor programming.
> The first one was doing the mapping from a vector of args to the
> parameter::parameters::bind.
>
> <code>
> template <typename Signature, typename Args>
> struct args;
>
> template <typename Signature, typename Arg0>
> struct args<Signature, mpl::vector<Arg0> > {
> typedef typename Signature::template bind<Arg0>::type type;
> };
>
> template <typename Signature, typename Arg0, typename Arg1>
> struct args<Signature, mpl::vector<Arg0, Arg1> > {
> typedef typename Signature::template bind<Arg0, Arg1>::type type;
> };
> </code>
>
> I don't know if there is a better way to do that, any hint is welcome.
>
> Any way I think that it will be easier to adapt the
> parameter::parameters::bind template to take a mpl sequence.
> See the definition of bind in boost/parameter/parameters.hpp
>
> <code>
> template <
> BOOST_PP_ENUM_BINARY_PARAMS(
> BOOST_PARAMETER_MAX_ARITY, class A, = void_ BOOST_PP_INTERCEPT
> )
> >
> struct bind
> {
> typedef typename aux::make_arg_list<
> typename BOOST_PARAMETER_build_arg_list(
> BOOST_PARAMETER_MAX_ARITY, aux::make_items, PS, A
> )::type
> , deduced_list
> , aux::tag_template_keyword_arg
> >::type result;
>
> typedef typename mpl::first<result>::type type;
> };
> </code>
>
> The second problem concern the mapping from a vector to a
> unmatched_signature, which is reduced to transform a mpl::vector to a
> mpl::or_
>
> <code>
> template <typename Param0,typename Param1>
> struct unmatched_signature<mpl::vector<Param0, Param1> >{
> typedef parameter::parameters<
> parameter::optional<
> parameter::deduced<
> detail::unmatched_arg
> >,
> mpl::not_<
> mpl::or_<
> typename Param0::pred,
> typename Param1::pred
> >
> >
> >
> > type;
> };
> </code>
>
> Is there something in boost that can simplify this mapping?
>
>
> Best Regards
>
> _______________________________________________
> Vicente Juan Botet Escriba
> _______________________________________________
>
> LUID DSL grammar
> _______________
> luidg(
> numeric_type(uint_type) ?
> & on_overflow(
> throw_on_error
> | errno_on_error
> | ignore_error
> | user_error(user_function)
> ) ?
> & on_release(
> discard
> | recover(
> recover_when?
> & recover_how?
> )
> ) ?
> & scope(
> mono_threaded
> | multi_threaded(locking? )
> | multi_process(locking? )
> ) ?
> & persistecy(
> process(
> void_pointer_type?
> & allocator_type?
> )
> | kernel(
> void_pointer_type?
> & allocator_type?
> & segment_manager_type?
> )
> | filesystem(
> void_pointer_type?
> & allocator_type?
> & segment_manager_type?
> )
> ) ?
> & optimization (
> speed
> | space
> ) ?
> & coherency (
> ensure(bitset | set | ...)?
> | ignore
> ) ?
> )
>
> recover_when (
> immediate
> | freeze
> | delay(time_traits)
> )
>
> recover_how (
> fifo
> | undefined
> )
>
> locking(
> internally(locking_traits)
> | externally(mutex_type)
> )
>
> locking_traits (
> thread_locking_traits
> | process_locking_traits
> | thread_recursive_locking_traits
> | process_recursive_locking_traits
> | ...
> )
>
> time_traits (
> posix_time_traits
> | ...
>
--------------------------------------------------------------------------------
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes:
Hi all,
The review of Eric Nieblers Proto library starts today, March 1st 2008, and will end on March 14th.
Could you be so nice to modify the main website to reflect this? I nearly missed this event and I think others also got used to the fact that reviews are announced on the website. I also request more time for the review. Proto is way too important and too complicated (for me) to be reviewed in such a short time. Markus
The review of Eric Nieblers Proto library starts today, March 1st 2008, and will end on March 14th.
Could you be so nice to modify the main website to reflect this? I nearly missed this event and I think others also got used to the fact that reviews are announced on the website.
Done. Thanks for pointing this out.
I also request more time for the review. Proto is way too important and too complicated (for me) to be reviewed in such a short time.
Let's cross this bridge when we're there. Regards Hartmut
Hello, here my review for Proto.
- What is your evaluation of the design? Very good. It is noticeable, that Proto has get many feedback from different projects like Spirit 2.
- What is your evaluation of the implementation? I haven't look into the implementation.
- What is your evaluation of the documentation?
I would likt to see more introduction and easy examples. And - as part of the introduction - what I can do with Proto. What are the advantages of usind expression templates instead of normal operator overloading? What can I do with Proto, which is not implementable with normal language features? Examples for transformation of expression.
I think, Eric should write a book for people like me, who is not a beginner of C++, but not a crack who makes the whole day metaprogramming.
- What is your evaluation of the potential usefulness of the library?
I think, it is very usefull, because with Proto I could implement little helpfull utilities like Assign very easy. And it is possible to create big DSELs like Spirit. But - I repeat myself - we need more beginner documentation to see and use the capabilities of Proto using.
- Did you try to use the library? With what compiler? Did you have any problems?
I work with the lib with MSV 2003, and I had no deep problems. Because of my limited knowledge of the domain and Proto it was hard to interpret the error messages.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I have read the whole documentation, but the second half only very fast. I have compile and test some examples. And I have try to build some little examples from scratch. In total I have spend 10 hours with Proto.
- Are you knowledgeable about the problem domain?
I have start using Spirit some years ago. And I was enthusiastic about the idea and the possibility of DSELs in C++. After that I tried two times to develop my own little DSEL, but it was difficult for me to understand and use expression templates. Therefore I fall back to normal operator overloading. With Proto this ideas become a new and better motivation.
Should Proto be accepted into Boost?
Yes - without any Restrictions.
Ciao Detlef
participants (4)
-
Detlef Wilkening -
Hartmut Kaiser -
Markus Werle -
vicente.botet