RE: [boost] [MPL] naming question
Greg Colvin wrote: > > > If this construct applies a metafuntion to a sequence > > > > It does and it doesn't :). Sorry if I wasn't clear about the > > semantics; it does not apply a metafunction to every element > > of a sequence; > > That would be for_each ? Almost - 'for_each' only makes sense if a (meta)function being called is allowed to have side effects; since a pure compile-time metafunction isn't (cannot), we don't have a pure compile-time 'for_each'. Instead, we have a whole family of 'fold' algorithms (http://www.mywikinet.com/mpl/ref/Algorithms.html), e.g.: typedef fold< numbers, int_c<0>, plus<_1,_2> >::type sum; What we do have on the 'for_each' side, is a "half run-time" algorithm that invokes an ordinary function on each element of a compile-time sequence: typedef mpl::range_c numbers; std::vector v; mpl::for_each( boost::bind(&std::vector::push_back, &v, _1) ); // equivalent to // v.push_back(0); // v.push_back(1); // ... // v.push_back(9); > > Yeah, unfortunately it can't be. You have to have different > > notation for invoking a function with a sequence of elements, > > 'cause just determining if the first and the only argument is > > a sequence and unrolling it is not enough - a (meta)function > > itself might expect exactly the original sequence, after all. > > Yep. Is there no way to use function call syntax for the > 0...n args case? As a matter of fact, it is, well, kind of: invoke< f(int,long) >::type // 'f' is a metafunction class here The only problem with the above is that it doesn't support certain types of argument very well (as highlighted in here: http://www.mail-archive.com/boost@lists.boost.org/msg00705.html), so when passing const, array, or 'void' types to a metafunction invoked in this manner, one has to do something like this: invoke< f(arg,long) >::type And it's not as portable as one would wish (for instance, gcc 3.2 chokes on some of those, not to speak about the other less capable compilers out there), so the combination of these factors pretty much rules it out, at least for now. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
David Abrahams wrote: thought, I am not sure if it's a good choice. Does apply< unarize, list >::type convey the discussed meaning for you? No, but I'm not sure that unroll_args does either. unroll_args doesn't, in fact, unroll arguments. It's a metafunction adapter. "Unroll" is usually used with loops, not arguments. But that might be the best name we can come up with. When I did this sort of thing on the runtime side, I called it "pack/unpack." What about "unpack_args?" -Dave -- "Some little people have music in them, but Fats, he was all music, and you know how big he was." -- James P. Johnson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> >> > >> > So, now the question is, how to name the adaptor? :) Does >> > 'unroll_args' sound right/good enough? >> >> Neat idea! How about "unary" or "unaryize"? > > I like the latter, but it doesn't appear to be a word; "unarize" is not a > word either, but at least google finds a couple of them :). On a second > thought, I am not sure if it's a good choice. Does > > apply< unarize, list >::type > > convey the discussed meaning for you? OK, I have two new ideas: on_arg_seq with_arg_seq I like the first one, though many people use "on_..." for something very different in event-driven code. The second one has some Lisp/Scheme tradition behind it, I believe... just in the "with_..." naming convention. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
>From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
> > With it, you might have used:
> >
> > template<>
> > struct plus
> > {
> > template
> > struct apply { ... }
> >
> > template
> > struct apply { ... }
> > };
> >
>
> Yes, except that I don't want to place a burden of supporting both forms
on
> a metafunction author. It's 'apply_tuple' that is supposed to take care of
> arguments unfolding and passing them on, separately, to the metafunction
> being invoked.
Yes, that makes sense.
> > And what about partial specialisation of function templates?
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1295.htm
Thanks. :) Come to think of it, I think I've read that proposal earlier.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
At 12:56 PM 1/4/2003, Aleksey Gurtovoy wrote:
>Greg Colvin wrote:
>> > If it was run-time C++, I would be happy with 'apply_tuple',
>> > but in MPL domain "tuple" isn't really the right word, and I
>> > don't like 'apply_seq' or, worse yet, 'apply_sequence'. Or
>> > should it be 'seq_apply' (from an English language standpoint)?
>>
>> If this construct applies a metafuntion to a sequence
>
>It does and it doesn't :). Sorry if I wasn't clear about the semantics; it
>does not apply a metafunction to every element of a sequence;
That would be for_each ?
>instead, it unrolls the sequence and passes all its elements to the
>metafunction as separate arguments, all at once.
>
>To clarify it further, here's how a run-time equivalent of that hypothetical
>'apply_tuple' could look like:
>
>template< typename F, typename Tuple >
>typename result_type::type
>do_apply(F f, Tuple const& args, arity<1>)
>{
>return f(get<0>(args));
>}
>
>template< typename F, typename Tuple >
>typename result_type::type
>do_apply(F f, Tuple const& args, arity<2>)
>{
>return f(get<0>(args), get<1>(args));
>}
>
>// ...
>
>template< typename F, typename Tuple >
>typename result_type::type
>apply(F f, Tuple const& args)
>{
>enum { n = tuple_length::value };
>return do_apply(f, args, arity());
>}
>
>void f(int, char const*);
>
>int main()
>{
>apply(f, make_tuple(5, "text")); // here
>}
>
>
>
>> then "apply_to_sequence" would be an accurate name.
>
>Thanks for clarifying the language side. Would it be still accurate for the
>aforementioned semantics?
Yes, if this is in some sense the "natural" thing to do.
>> Too bad it can't just be "apply".
>
>Yeah, unfortunately it can't be. You have to have different notation for
>invoking a function with a sequence of elements, 'cause just determining if
>the first and the only argument is a sequence and unrolling it is not enough
>- a (meta)function itself might expect exactly the original sequence, after
>all.
Yep. Is there no way to use function call syntax for the 0...n args case?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
Terje Slettebø wrote:
> I guess this is another good argument for class template
> overloading. Does anyone know if this has been "formally"
> proposed for C0x?
AFAIK, no.
> A quick search at Google Groups turned up nothing.
>
> With it, you might have used:
>
> template<>
> struct plus
> {
> template
> struct apply { ... }
>
> template
> struct apply { ... }
> };
>
Yes, except that I don't want to place a burden of supporting both forms on
a metafunction author. It's 'apply_tuple' that is supposed to take care of
arguments unfolding and passing them on, separately, to the metafunction
being invoked.
> And what about partial specialisation of function templates?
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1295.htm
> Could there be a good chance to get that, as well? I guess these things
> depend much on somebody writing a formal proposal. :)
In particular.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> >> > >> > So, now the question is, how to name the adaptor? :) Does >> > 'unroll_args' sound right/good enough? >> >> Neat idea! How about "unary" or "unaryize"? > > I like the latter, but it doesn't appear to be a word; "unarize" is not a > word either, but at least google finds a couple of them :). "as_unary"? > On a second > thought, I am not sure if it's a good choice. Does > > apply< unarize, list >::type > > convey the discussed meaning for you? No, but I'm not sure that unroll_args does either. unroll_args doesn't, in fact, unroll arguments. It's a metafunction adapter. "Unroll" is usually used with loops, not arguments. But that might be the best name we can come up with. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > > > So, now the question is, how to name the adaptor? :) Does > > 'unroll_args' sound right/good enough? > > Neat idea! How about "unary" or "unaryize"? I like the latter, but it doesn't appear to be a word; "unarize" is not a word either, but at least google finds a couple of them :). On a second thought, I am not sure if it's a good choice. Does apply< unarize, list >::type convey the discussed meaning for you? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
Greg Colvin wrote:
> > If it was run-time C++, I would be happy with 'apply_tuple',
> > but in MPL domain "tuple" isn't really the right word, and I
> > don't like 'apply_seq' or, worse yet, 'apply_sequence'. Or
> > should it be 'seq_apply' (from an English language standpoint)?
>
> If this construct applies a metafuntion to a sequence
It does and it doesn't :). Sorry if I wasn't clear about the semantics; it
does not apply a metafunction to every element of a sequence;
instead, it unrolls the sequence and passes all its elements to the
metafunction as separate arguments, all at once.
To clarify it further, here's how a run-time equivalent of that hypothetical
'apply_tuple' could look like:
template< typename F, typename Tuple >
typename result_type::type
do_apply(F f, Tuple const& args, arity<1>)
{
return f(get<0>(args));
}
template< typename F, typename Tuple >
typename result_type::type
do_apply(F f, Tuple const& args, arity<2>)
{
return f(get<0>(args), get<1>(args));
}
// ...
template< typename F, typename Tuple >
typename result_type::type
apply(F f, Tuple const& args)
{
enum { n = tuple_length::value };
return do_apply(f, args, arity());
}
void f(int, char const*);
int main()
{
apply(f, make_tuple(5, "text")); // here
}
> then "apply_to_sequence" would be an accurate name.
Thanks for clarifying the language side. Would it be still accurate for the
aforementioned semantics?
> Too bad it can't just be "apply".
Yeah, unfortunately it can't be. You have to have different notation for
invoking a function with a sequence of elements, 'cause just determining if
the first and the only argument is a sequence and unrolling it is not enough
- a (meta)function itself might expect exactly the original sequence, after
all.
Thanks,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > So, now the question is, how to name the adaptor? :) Does 'unroll_args' > sound right/good enough? Neat idea! How about "unary" or "unaryize"? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
David Abrahams wrote:
> > How would you call an 'apply' counterpart that takes a
> > metafunction class and a _sequence_ of arguments, i.e.:
> >
> > typedef list_c args;
> > typedef apply_tuple< plus<>, args >::type sum; // this one
> > BOOST_STATIC_ASSERT(sum::value == 5);
> >
> > ?
>
> I don't know. In Python, the one that takes an argument tuple is
> called "apply", and the other one is called "function call syntax" ;-)
I knew about the former, but I wondered how the second one is called :).
>
> > If it was run-time C++, I would be happy with 'apply_tuple',
> > but in MPL domain "tuple" isn't really the right word, and I
> > don't like 'apply_seq' or, worse yet, 'apply_sequence'. Or
> > should it be 'seq_apply' (from an English language standpoint)?
> >
> > Anyway, suggestions and opinions are welcome!
>
> I'm afraid I'm stumped also.
> If you were willing to make a massive change, I'd suggest:
>
>call this one 'apply'
>call the other one 'call' or 'invoke'
>
> Though I don't particularly like it.
Me too, but thanks for the suggestion.
> Why is 'apply' more appropriate
> for this one, other than consistency with some other language?
It's not indeed.
> I think 'apply_args' sounds right, though they both let you specify
> arguments.
I thought of this one too, and had the same concern...
> Maybe 'apply_arg_sequence' is appropriate?
This one is not bad, although 'apply_arg_sequence' probably too long
for a metafunction invocation syntax. May be a shorter abbreviation of it,
'apply_arg_seq'?
Hmm, actually, come to think about it more, there is no reason to stick
arguments unfolding _and_ consequent function application into the same
metafunction. In fact, separating those two, besides conceptual clarity,
might yield some practical benefits as well - one might want to adapt a
metafunction class and just pass it on, with the invocation happening later
on, if at all.
So, instead of single 'apply_arg_seq' construct that does this
apply_arg_seq::type ==
apply::type
we can just have ordinary 'apply' + a metafunction class adaptor that
unrolls the argument sequence:
unroll_args == adapted_F
apply< unroll_args,Args >::type
== apply::type
where 'adapted_F' implements the actual unrolling:
struct adapted_F
{
template< typename Args > struct apply
: apply
{
};
};
So, now the question is, how to name the adaptor? :) Does 'unroll_args'
sound right/good enough?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
>From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
>
> > How would you call an 'apply' counterpart that takes a metafunction
class
> > and a _sequence_ of arguments, i.e.:
> >
> template<>
> struct plus
> {
> template
> struct apply { ... }
>
> template
> struct apply { ... }
> };
Since this doesn't exist, maybe one could use something like:
template
struct plus { ... };
// Specialisation for sequence
template
struct plus { ... };
And the same for the lambda version (with the apply-member). This does use
partial specialisation, though.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
>From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
> How would you call an 'apply' counterpart that takes a metafunction class
> and a _sequence_ of arguments, i.e.:
>
> typedef list_c args;
> typedef apply_tuple< plus<>, args >::type sum; // this one
> BOOST_STATIC_ASSERT(sum::value == 5);
>
> ?
>
> If it was run-time C++, I would be happy with 'apply_tuple', but in MPL
> domain "tuple" isn't really the right word, and I don't like 'apply_seq'
or,
> worse yet, 'apply_sequence'. Or should it be 'seq_apply' (from an English
> language standpoint)?
>
> Anyway, suggestions and opinions are welcome!
I guess this is another good argument for class template overloading. Does
anyone know if this has been "formally" proposed for C0x? A quick search at
Google Groups turned up nothing.
With it, you might have used:
template<>
struct plus
{
template
struct apply { ... }
template
struct apply { ... }
};
And what about partial specialisation of function templates? Could there be
a good chance to get that, as well? I guess these things depend much on
somebody writing a formal proposal. :)
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > Hi all, > > How would you call an 'apply' counterpart that takes a metafunction class > and a _sequence_ of arguments, i.e.: > > typedef list_c args; > typedef apply_tuple< plus<>, args >::type sum; // this one > BOOST_STATIC_ASSERT(sum::value == 5); > > ? I don't know. In Python, the one that takes an argument tuple is called "apply", and the other one is called "function call syntax" ;-) > If it was run-time C++, I would be happy with 'apply_tuple', but in MPL > domain "tuple" isn't really the right word, and I don't like 'apply_seq' or, > worse yet, 'apply_sequence'. Or should it be 'seq_apply' (from an English > language standpoint)? > > Anyway, suggestions and opinions are welcome! I'm afraid I'm stumped also. If you were willing to make a massive change, I'd suggest: call this one 'apply' call the other one 'call' or 'invoke' Though I don't particularly like it. Why is 'apply' more appropriate for this one, other than consistency with some other language? I think 'apply_args' sounds right, though they both let you specify arguments. Maybe 'apply_arg_sequence' is appropriate? -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
At 02:54 AM 1/4/2003, you wrote: >Hi all, > >How would you call an 'apply' counterpart that takes a metafunction class >and a _sequence_ of arguments, i.e.: > >typedef list_c args; >typedef apply_tuple< plus<>, args >::type sum; // this one >BOOST_STATIC_ASSERT(sum::value == 5); > >? > >If it was run-time C++, I would be happy with 'apply_tuple', but in MPL >domain "tuple" isn't really the right word, and I don't like 'apply_seq' or, >worse yet, 'apply_sequence'. Or should it be 'seq_apply' (from an English >language standpoint)? If this construct applies a metafuntion to a sequence then "apply_to_sequence" would be an accurate name. Too bad it can't just be "apply". ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] naming question
Hi all, How would you call an 'apply' counterpart that takes a metafunction class and a _sequence_ of arguments, i.e.: typedef list_c args; typedef apply_tuple< plus<>, args >::type sum; // this one BOOST_STATIC_ASSERT(sum::value == 5); ? If it was run-time C++, I would be happy with 'apply_tuple', but in MPL domain "tuple" isn't really the right word, and I don't like 'apply_seq' or, worse yet, 'apply_sequence'. Or should it be 'seq_apply' (from an English language standpoint)? Anyway, suggestions and opinions are welcome! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
