Re: [boost] [Fwd: Re: [proto]possible morphism design (was Re: Proto review: a humble request]

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-26 12:47:06

Larry Evans wrote:
> Hi Eric.
> 
> Apparently some of my posts aren't getting through.  I posted
> the attached before my reply to Hartmut, but it hasn't made it
> to the newsgroup yet.  So, I thought you might like a look at
> it.

Do you post messages to GMane or email them to the list. I do the later.

From: Larry Evans <cppljevans_at_[hidden]>
> On 03/24/08 17:15, Eric Niebler wrote:
<snip>
> > I can't tell where we are getting confused, but I
> > suspect that you've been misled by the role of the terminal<>, negate<>,
> > plus<>, etc. meta-functions. They are not expression types ... they are
> > meta-functions that generate expression types.
> 
> Yes.  I'm embarrassed.  I was away from the thread awhile and forgot
> that in the expr equation here:
> 
> http://archives.free.net.ph/message/20080322.024505.84b8c598.en.html
> 
> expr *only* meant instances of proto::expr<Tag,Args,Arity>
> for some Tag,Args, and Arity.
> 
> The reason I added the ::type later was because I remembered that
> using the meta-functions required that to produce an expression and
> also, somewhere in my testing (can't remember where, ATM) I had to
> append ::type to the args to a meta-function template's args to get an
> expression.
> 
> Sorry, I should have been more careful.

No problem. Glad the fog of confusion is thinning.

<snip>

> > you can't convert a proto grammar to a proto expression type, in
> > general.
> 
> The 'in general' is the key phrase there.  I wasn't attempting to
> convert the grammars that weren't convertible.  The grammars that
> *are* convertible are those formed from the 'meta-functions that
> generate expression types'( as you said above) *and* whose arguments
> have been *similarly converted* (otherwise, an argument could be a
> grammar and consequently the conversion result *wouldn't* be an
> expression type).
> 
> > We've covered this ground already ... grammar types are a
> > super-set of expression types.
> 
> I know.  I'm sorry.  I just hadn't got firm in my mind that
> I was talking about expression types instead of meta-function
> generators.  The probable reason is that:
> 
>   meta-function<Args> is a grammar
> 
>   meta-function<Args>::type is an expression_type
>     (under certain restrictions on Args)

Correct.

> and:
> 
>   expression_type is a grammar
> 
> got me mixed up and lead me to jump to the conclusion:
> 
>   expression_type::type is an expression type
> 
> when, in fact, there's no such nested type.  I supposed that
> expression_type::type simply equaled expression_type (which is what
> mpl meta-functions often do, IIRC).

Right, expr<> doesn't have a nested ::type typedef. It used to, but it 
got renamed to ::proto_base_expr.

> [snip]
> >
> > Any formalism that is based on
> > converting a proto grammar to a proto expression by accessing a nested
> > ::type typedef is wrong. Grammars are not convertible to expressions.
> > The meta-functions that generate expression types are not expressions
> > themselves. They are meta-functions.
>
> From:
> 
>   The meta-functions are also *usable as grammars* for matching such nodes
> 
> on:
> 
> libs/proto/doc/html/boost_proto/users_guide/expression_construction/tags_and_meta_functions.html 
> 
> a meta-function *is* a grammar and can be used to "generate expression
> types"(quoting you).  Maybe instead of "grammar conversion to
> expression" I should have said "meta-function grammar use to generate
> an expression".

Hmm, ok.

> I assume an example of this is:
> 
>   terminal<int>::type
> 
> where grammar, terminal<int> (it's a grammar according to the above
> .html reference), is used to generate the expression type,
> expr<tag:terminal,args0<int> >.
> 
> ==============================================
> Now, back to the question of morphisms.  If the source algebra is just
> meta-function grammars whose arguments are also meta-function grammars,
> then there's a morphism from that to the target algebra which is expression
> types.  The morphism, f, is simply applying the meta-function
> recursively.  The base case, is of course, the terminals:
> 
>   base_case:
> 
>     terminal<T>       //a meta-function grammar in source algebra.
>     f<terminal<T> >::type
>     ==>  terminal<T>::type //the corresponding expression in the target
>                            //algebra.

Yes.

> 
>   recursive_case:
> 
>     metafun<M1,M2,...Mn> //a meta-function grammar.
> 
>     f<metafun<M1,M2,...,Mn> >::type
>     ==> metafun<f<M1>::type,f<M1>::type,...,f<Mn>::type>::type
>         //^the corresponding expression in target algebra.

Ah, yes.

> here, metafun can be any of the meta-functions listed here:
> 
> libs/proto/doc/html/boost_proto/users_guide/expression_construction/tags_and_meta_functions.html 
> 
> (except maybe the if_else_).  The attached compiles and shows that the
> above at least works for the morphism between 0-ary and 1-ary
> meta-functions and expressions.  The attached uses morphism instead of
> f as the name of the morphism.

OK! I understand that, and it is correct in the limited case of those 
dual-purpose grammars-and-metafunctions.

I'm re-attaching your code, in case others want to see it.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com