Re: [proto] expanding Proto's library of callables

2010-12-28 Thread Thomas Heller
Eric Niebler wrote:

 Proto ships with a very small collection of callables for use in Proto
 transforms: wrappers for fusion algorithms like reverse and pop_front
 and the like. For 1.46, there will be a few more: make_pair, first,
 second, and wrappers for a few more Fusion algorithms. It's woefully
 incomplete, though.
 
 I have an idea. Phoenix3 defines *all* these juicy callables under the
 stl/ directory. I can't #include them in Proto because that would create
 a circular dependency. Why don't we just move the definitions of the
 function objects into Proto and make them Proto callables? Phoenix3 can
 just #include 'em and use 'em.
 
 Thoughts?

I just saw that you added functional::at.
I was wondering about the rationale of your decision to make it a non 
template.
My gut feeling would have been to have proto::functional::atN(seq)
and not proto::functional::at(seq, N).
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] expanding Proto's library of callables

2010-12-28 Thread Eric Niebler
On 12/28/2010 5:39 AM, Thomas Heller wrote:
 I just saw that you added functional::at.
 I was wondering about the rationale of your decision to make it a non 
 template.
 My gut feeling would have been to have proto::functional::atN(seq)
 and not proto::functional::at(seq, N).

Think of the case of Phoenix placeholders, where in the index is a
parameter:

  when terminalplaceholder_ , _at(_state, _value) 

For the times when the index is not a parameter, you can easily do:

  _at(_state, mpl::int_N())

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] expanding Proto's library of callables

2010-12-28 Thread Thomas Heller
Eric Niebler wrote:

 On 12/28/2010 5:39 AM, Thomas Heller wrote:
 I just saw that you added functional::at.
 I was wondering about the rationale of your decision to make it a non
 template.
 My gut feeling would have been to have proto::functional::atN(seq)
 and not proto::functional::at(seq, N).
 
 Think of the case of Phoenix placeholders, where in the index is a
 parameter:
 
   when terminalplaceholder_ , _at(_state, _value) 

vs:

whenterminalplaceholder_ , _at_value(_state)

 For the times when the index is not a parameter, you can easily do:
 
   _at(_state, mpl::int_N())

vs:

_atmpl::int_N (_state)

just wondering ... the second version looks more natural and consistent
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] expanding Proto's library of callables

2010-12-28 Thread Eric Niebler
On 12/28/2010 11:43 AM, Thomas Heller wrote:
 Eric Niebler wrote:
 
 On 12/28/2010 5:39 AM, Thomas Heller wrote:
 I just saw that you added functional::at.
 I was wondering about the rationale of your decision to make it a non
 template.
 My gut feeling would have been to have proto::functional::atN(seq)
 and not proto::functional::at(seq, N).

 Think of the case of Phoenix placeholders, where in the index is a
 parameter:

   when terminalplaceholder_ , _at(_state, _value) 
 
 vs:
 
 whenterminalplaceholder_ , _at_value(_state)

Have you tried that? Callable transforms don't work that way. It would
have to be:

 lazyat_value(_state)

Blech.

 For the times when the index is not a parameter, you can easily do:

   _at(_state, mpl::int_N())
 
 vs:
 
 _atmpl::int_N (_state)
 
 just wondering ... the second version looks more natural and consistent

Still think so?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] expanding Proto's library of callables

2010-12-28 Thread Thomas Heller
Eric Niebler wrote:

 On 12/28/2010 11:43 AM, Thomas Heller wrote:
 Eric Niebler wrote:
 
 On 12/28/2010 5:39 AM, Thomas Heller wrote:
 I just saw that you added functional::at.
 I was wondering about the rationale of your decision to make it a non
 template.
 My gut feeling would have been to have proto::functional::atN(seq)
 and not proto::functional::at(seq, N).

 Think of the case of Phoenix placeholders, where in the index is a
 parameter:

   when terminalplaceholder_ , _at(_state, _value) 
 
 vs:
 
 whenterminalplaceholder_ , _at_value(_state)
 
 Have you tried that? Callable transforms don't work that way. It would
 have to be:
 
  lazyat_value(_state)
 
 Blech.

Right ... i keep forgetting about that ...

 For the times when the index is not a parameter, you can easily do:

   _at(_state, mpl::int_N())
 
 vs:
 
 _atmpl::int_N (_state)
 
 just wondering ... the second version looks more natural and consistent
 
 Still think so?


Nope. Let's have it your way :)

One other thing though ...

struct at
{
BOOST_PROTO_CALLABLE()

templatetypename Sig
struct result;

templatetypename This, typename Seq, typename N
struct resultThis(Seq, N)
  : fusion::result_of::at
typename boost::remove_referenceSeq::type
  , typename boost::remove_consttypename 
boost::remove_referenceN::type::type

{};

templatetypename Seq, typename N
typename fusion::result_of::atSeq, N::type
operator ()(Seq seq, N const  
BOOST_PROTO_DISABLE_IF_IS_CONST(Seq)) const
{
return fusion::atN(seq);
}

templatetypename Seq, typename N
typename fusion::result_of::atSeq const, N::type
operator ()(Seq const seq, N const ) const
{
return fusion::atN(seq);
}
};

VS:

struct at
{
BOOST_PROTO_CALLABLE()

templatetypename Sig
struct result;

templatetypename This, typename Seq, typename N
struct resultThis(Seq, N)
: resultThis(Seq const , N)
{};

templatetypename This, typename Seq, typename N
struct resultThis(Seq , N)
  : fusion::result_of::at
Seq
  , typename proto::detail::uncvrefN::type

{};

templatetypename Seq, typename N
typename fusion::result_of::atSeq, N::type
operator ()(Seq seq, N const  
BOOST_PROTO_DISABLE_IF_IS_CONST(Seq)) const
{
return fusion::atN(seq);
}

templatetypename Seq, typename N
typename fusion::result_of::atSeq const, N::type
operator ()(Seq const seq, N const ) const
{
return fusion::atN(seq);
}
};

I think the second version instantiates less templates than the first one.
___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] expanding Proto's library of callables

2010-12-20 Thread Joel de Guzman

On 12/19/2010 12:21 AM, Thomas Heller wrote:



Eric Niebler wrote:


Proto ships with a very small collection of callables for use in Proto
transforms: wrappers for fusion algorithms like reverse and pop_front
and the like. For 1.46, there will be a few more: make_pair, first,
second, and wrappers for a few more Fusion algorithms. It's woefully
incomplete, though.

I have an idea. Phoenix3 defines *all* these juicy callables under the
stl/ directory. I can't #include them in Proto because that would create
a circular dependency. Why don't we just move the definitions of the
function objects into Proto and make them Proto callables? Phoenix3 can
just #include 'em and use 'em.



Thoughts?


Wonderful idea! I like it.


Good idea. Let's do it.

Regards,
--
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net



___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto


Re: [proto] expanding Proto's library of callables

2010-12-19 Thread Thomas Heller


Eric Niebler wrote:

 Proto ships with a very small collection of callables for use in Proto
 transforms: wrappers for fusion algorithms like reverse and pop_front
 and the like. For 1.46, there will be a few more: make_pair, first,
 second, and wrappers for a few more Fusion algorithms. It's woefully
 incomplete, though.
 
 I have an idea. Phoenix3 defines *all* these juicy callables under the
 stl/ directory. I can't #include them in Proto because that would create
 a circular dependency. Why don't we just move the definitions of the
 function objects into Proto and make them Proto callables? Phoenix3 can
 just #include 'em and use 'em.



 Thoughts?

Wonderful idea! I like it.

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto