Re: [boost] [proto] grammar matching issue

From: Maurizio Vitale (maurizio.vitale_at_[hidden])
Date: 2007-06-14 22:59:37

On Jun 14, 2007, at 7:00 PM, Eric Niebler wrote:

>
> Maurizio Vitale wrote:
>> On Jun 14, 2007, at 12:57 PM, Eric Niebler wrote:
>>
>>> Maurizio Vitale wrote:
>>>> if you could find a way to completely hide the fact that a
>>>> terminal is
>>>> a unary_expr from the user I think it would be much cleaner for
>>>> a boost::proto release.
>>> I'll give the issue some thought. One possibility is shoehorn into
>>> proto
>>> the concept of a nullary expression, which is what terminals should
>>> rightly be. Of course, what is there already works, so IMO there are
>>> bigger fish to fry first.
>>
>> I think "usability" considerations play a big role in a library
>> acceptance.
>
> I'm willing to bet that you have been taking advantage of the  
> usability
> that terminals-as-unary-expressions brings, without even noticing it.
>
> Q: How do you get the argument of a unary expression?
> A: proto::arg().
>
> Q: How do you get the value out of a terminal?
> A: proto::arg().
>
> This works because terminals have one "argument", just as unary
> expressions do. I like this. I don't want to have to use a separate
> function to extract the argument from a terminal. But if I draw a  
> crisp
> line between terminals and unary expressions, I might have to.

Maybe. I don't have the familiarity you have with the implementation.

I don't immediately see why between overloading (for run-time calls) and
specialization (for compile-time dispatching) it shouldn't be  
possible to
have the same name for proto::arg() for terminals and unary_expr
(with different implementations where needed).

But if it comes to that, I'd personally prefer different names  
for ::arg than unary_function
matching a terminal: the former is easy to learn and getting it wrong  
would result
in compiler errors, the latter can result in hard to track errors.

> Otherwise, the line stays blurry.
>
> I really don't think it's as cut-and-dry as you make it. I'll think
> about it.
>