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@suddenlink.net>

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