On Thu, Mar 26, 2015 at 12:54 PM, Thomas 'PointedEars' Lahn <pointede...@web.de> wrote: > Ian Kelly wrote: >> What I mean is that if you construct a parse tree of "foo" "bar" using >> that grammar, it looks like this: >> >> expr >> | >> STRING+ >> / \ >> STRING STRING >> […] >> >> There is only one expr node, and it contains both STRING tokens. > > Prove it.
I'm not going to expend the effort that would be required to go through the entire Python grammar step-by-step and exhaustively prove that "foo" "bar" can unambiguously only be produced as a single expr. If you believe otherwise, show a parse tree that parses these as separate expressions. > But be warned: Neither would prove that a string literal is not an > expression. I've not claimed that a string literal is not an expression. My claim is that a literal consisting of the implicit concatenation of more than one string token is can only be parsed as one expression, not several. Parsing "foo" "bar" > Because you did not consider the most simple variant of an AST > (or subtree) according to this grammar: > > expr > | > STRING Of course I did. This is again *exactly* what I was talking about in reference to parsing the individual strings in isolation. > Again, “STRING+” does _not_ mean “STRING STRING STRING*”; it means “STRING > STRING*”. The second and following STRINGs are *optional*. Please stop speaking down to me. I'm quite familiar with basic concepts of EBNF. >>> […] in the used flavour of EBNF the unquoted “+” following a goal symbol >>> clearly means the occurrence of *at least one* of the immediately >>> preceding symbol, meaning either one *or more than one*. >> >> It means one or more *tokens*, not one or more literals. > > Utter nonsense. Have you ever written a parser? (I have.) Yes. > A literal *is* > a token. Whether two consecutive tokens end up as the same *node* in an AST > is a *different* issue (that, again, was _not_ debated). I was going to respond with a comment about how literals are a type of expression, not token, using a literal tuple as an example of a literal that is not a token. Then I checked the docs and noticed that the language reference actually shies away from calling this a literal and uses the phrase "container display" instead. Browsing through the specifications of a few other languages (e.g. ECMAscript, which has so-called "object literals"), they all seem to share the pattern of using "literal" strictly to mean a type of token in their specs, despite the word taking on a much broader meaning when writing informally. So I'll have to concede that point as well. -- https://mail.python.org/mailman/listinfo/python-list
