Boost logo

Boost :

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:
> > 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:
> 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.


> > 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)


> 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.


> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at