Proto's review ends this Friday. There's been good discussion, but very few actual reviews. Please consider writing a review, if you haven't already. Thanks in advance, -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Proto's review ends this Friday. There's been good discussion, but very few actual reviews. Please consider writing a review, if you haven't already.
Oh man... the easter holiday got ahold of me... I'm writing one now. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 03/23/08 15:18, Eric Niebler wrote:
Proto's review ends this Friday. There's been good discussion, but very few actual reviews. Please consider writing a review, if you haven't already.
Hi Eric, I've been struggling with the review; however, I still have a number of questions about the design. That's why I haven't been able to make a review that I'm reasonably sure would be justifiable. For instance, I've had problems understanding the difference between a proto expression and a grammar and summarizing that difference in some sort of succinct formula. My last attempt was: http://archives.free.net.ph/message/20080324.160640.f8aed314.en.html My tentative conclusion is that a better design, more along the lines of algebraic morphisms, would make proto easier to understand. The only way I could be reasonably sure of this would be to try and prototype this. <excuse_for_maybe_flawed_review> Since that would take *way* too long, I'll just jump to that conclusion (and possibly several others) in my review </excuse_for_maybe_flawed_review> and wait for your response about if it's not workable and why. -regards, Larry
Larry Evans wrote:
On 03/23/08 15:18, Eric Niebler wrote:
Proto's review ends this Friday. There's been good discussion, but very few actual reviews. Please consider writing a review, if you haven't already.
Hi Eric,
I've been struggling with the review; however, I still have a number of questions about the design. That's why I haven't been able to make a review that I'm reasonably sure would be justifiable. For instance, I've had problems understanding the difference between a proto expression and a grammar and summarizing that difference in some sort of succinct formula. My last attempt was:
http://archives.free.net.ph/message/20080324.160640.f8aed314.en.html
I confess I don't understand your notation in that message. 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?
My tentative conclusion is that a better design, more along the lines of algebraic morphisms, would make proto easier to understand. The only way I could be reasonably sure of this would be to try and prototype this.
<excuse_for_maybe_flawed_review> Since that would take *way* too long, I'll just jump to that conclusion (and possibly several others) in my review </excuse_for_maybe_flawed_review>
I would hope that if you're arguing for a better design that you could describe what that better design looks like.
and wait for your response about if it's not workable and why.
You'd have to say what "it" is before I can say whether it's workable or not. -- Eric Niebler Boost Consulting www.boost-consulting.com
On 03/24/08 15:16, Eric Niebler wrote:
Larry Evans wrote:
sort of succinct formula. My last attempt was:
http://archives.free.net.ph/message/20080324.160640.f8aed314.en.html
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 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' 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. 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: '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.
Larry Evans wrote:
On 03/24/08 15:16, Eric Niebler wrote:
Larry Evans wrote:
sort of succinct formula. My last attempt was:
http://archives.free.net.ph/message/20080324.160640.f8aed314.en.html
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 ::type. 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
Huh?
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 www.boost-consulting.com
Larry, Let me first state that I have to admit to have a very hard time to follow your discussion with Eric. Before this review I actually thought to understand Proto (and I've been using it for quite some time during the Spirit development)....
On 03/24/08 15:16, Eric Niebler wrote:
Larry Evans wrote:
sort of succinct formula. My last attempt was:
http://archives.free.net.ph/message/20080324.160640.f8aed314.en.html
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 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'
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. 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:
'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
Could you please clarify what you're trying to achieve with this notation? Is this meant as an alternative notation of expressing proto grammars? Currently I'm not able to put this in a meaningful relation with Proto, but this might be my ignorance.
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?
I second Eric's question. What is a morphism in this context and how does it relate to the discussion of Proto. I take it you're using the term 'morphism' in the mathematical sense of being an "abstraction derived from structure-preserving mappings between two mathematical structures" (taken from Wikipedia here: http://en.wikipedia.org/wiki/Morphism). What are you trying to map onto what? Regards Hartmut
On 03/25/08 19:12, Hartmut Kaiser wrote:
Larry,
Let me first state that I have to admit to have a very hard time to follow your discussion with Eric. Before this review I actually thought to understand Proto (and I've been using it for quite some time during the Spirit development)....
Sorry I'm not being more understandable :( Maybe I'm trying to "shoe-horn" proto's description into a formalism where it won't fit. OTOH, I've had a lot of trouble myself in getting it to do what I want, which is pretty easy to express in this formalism. Maybe your use is not very similar to mine. Maybe you have easier access and interaction with Eric and others dealing with proto. Interesting question. I know I've had trouble before making myself clear; so, maybe I just have to work harder at that. [snip]
where the concrete symbols corresponding to the last step in the example abstract derivation above are:
'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
Could you please clarify what you're trying to achieve with this notation? Is this meant as an alternative notation of expressing proto grammars?
Yes. I was trying to distill the description to just the essence of the difference between a grammar and expression. In the reply I just made to Eric's post, I admitted the problem (or at least most of it) was due to my jumping to conclusions.
Currently I'm not able to put this in a meaningful relation with Proto, but this might be my ignorance.
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?
I second Eric's question. What is a morphism in this context and how does it relate to the discussion of Proto. I take it you're using the term 'morphism' in the mathematical sense of being an "abstraction derived from structure-preserving mappings between two mathematical structures" (taken from Wikipedia here: http://en.wikipedia.org/wiki/Morphism). What are you trying to map onto what?
The last part of my recent reply to Eric's post is hopefully clearer. It comes with an attachment which illustrates the morphism. I hope that's clear enough. If not, I still need to work on my communication skills some more :( I've also used a different definition of morphism: http://planetmath.org/encyclopedia/HomomorphismBetweenAlgebraicSystems.html The one you cited is closer to category theory which, AFAICT, is more abstract than the planetmath definition. BTW, I appreciate both your feedback (letting me know I'm not being clear) and Eric's in helping me better understand proto. I know it's tough! -regards, Larry
participants (4)
-
Eric Niebler -
Hartmut Kaiser -
Joel de Guzman -
Larry Evans