Re: [boost] Interest in DSL framework

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-08-14 19:59:01

Andreas Pokorny wrote:
> Hi, 
> 
> "Andy Little" wrote 
>> "Joel de Guzman" wrote
>>> IIUC, the "rule" specifies the result type (not deduces the
>>> result type). I think it's not a macro at all; it would rather
>>> be something like: "unspecified_type", or
>>> "you-define-your-type-here-and-ill-do-the-rest"
>> Well again I am probably not understanding it fully, but from  one of
>> Andreas
>> posts higher in the thread:
>>
>> get_result_type<add_tag,LeftT,RightT>
>>
>> presumably could be implemented as:
>>
>> template <typename LeftT, typename RightT>
>> struct get_result_type<add_tag,LeftT,RightT>
>> {
>>     typedef BOOST_TYPEOF_TPL(LeftT() + RightT()) type;
>> };
> 
> That would be a hen-egg situation. The result_type of the 
> operator is defined by the rules, not the other way around. 
> Like the Joel said, the encoding of the expression tree into 
> operator and function return types is up to the user.
> 
> The frontend of the DSLs built with this framework consist of
> overloaded operators (already provided by the framework), and 
> small user defined inline functions (probably created using a framework macro). 
> These functions invoke the rule system with the operands, and 
> an operator tag which identifies the function or operator. The 
> result type is deduced by finding a matching rule, the result
> (value) is returned after calling a static method inside the 
> rule found.
> 
> So the user might even refuse to encode the expression inside a rule,
> but evaluate the expression directly and return the result of the
> evaluation.  

Right. But then again, the ET framework will always benefit from
typeof/auto:

     auto csv = int_ >> *(',' >> int_);

or, in the interim:

     BOOST_AUTO(csv, int_ >> *(',' >> int_));

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