Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-24 18:15:13

Larry Evans wrote:
> On 03/24/08 15:16, Eric Niebler wrote:
> > Larry Evans wrote:
> >> sort of succinct formula. My last attempt was:
> >>
> >>
> >
> >
> > I confess I don't understand your notation in that message.
> The notation is supposed to be a language grammar similar to that
> shown in compiler texts, except it doesn't surround the grammar
> terminals with quotes. So, to make it closer to that, use:
> expr_type
> = 'terminal::type' //rule0
> | (expr_type+)'::type' //rule1
> ;
> and where the postfix + means 1 or more of the preceding. So, one

I'm afraid you've lost me already. There is no sense in which it is
correct to say that an expression is one or more expressions followed by

I explained in my other mail what the allowable expression types are. It
has nothing to do with any nested ::type.

> possible instance of sentence satisfying this grammar is (tracing the
> derivations and subscripting different instances of grammar symbols with
> _i, where i is an positive integer, and showing the derivations steps
> with -(ruleX->, where ruleX is one of the comments labelling
> the grammar altenatives in the above equattion):
> expr_type
> -rule1-> (expr_type_1, expr_type_2, expr_type_3)'::type'
> -rule0-> ('terminal::type'_1 'terminal::type'_2
> 'terminal::type'_3)'::type'

Sorry, I don't get it. 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. metafunctions. They are not expression types ... they are
metafunctions that generate expression types.

> Now, the terminal symbol, 'terminal::type' is supposed to represent
> any proto::terminal<> grammar


> and the appending '::type' is supposed
> to represent the conversion of the proto::grammar to the corresponding
> expression.

No, you can't convert a proto grammar to a proto expression type, in
general. We've covered this ground already ... grammar types are a
superset of expression types.

> The (expr_type+) is supposed to represent any other
> proto "expression" grammar. The reason expr<Tag,expr_type+,Size> was
> not used was because that's just the concrete syntax version of
> expr_type+; hence, just detail. A concrete instance of this would be:
> shift_right<terminal<int>::type,terminal<char>::type>::type
> where the concrete symbols corresponding to the last step in the example
> abstract derivation above are:

It seems you're trying to express the expression concept in terms of the
metafunctions that generate expressions. That's not right.

> 'terminal::type'_1
> == terminal<int>::type
> 'terminal:;type'_2
> == terminal<char>::type
> 'terminal::type'_3
> == //none because shift_right is binary
> ('terminal::type'_1 'terminal::type'_2)'::type'
> == shift_right<terminal<int>,terminal<char>::type>::type
> > I also don't
> > understand what you're trying to get at with morphisms, a concept I
> > don't grasp. Do you think you could try again to explain what you're
> > trying to achieve?
> >
> Before I try that, I better make sure the above is clear enough.
> Could you let me know if it's not clear.

I'm afraid I'm not getting it yet, sorry. 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 metafunctions that generate expression types are not expressions
themselves. They are metafunctions.

Eric Niebler
Boost Consulting

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