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