Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #87687 > unrolled thread

A simple single line, triple-quoted comment is giving syntax error. Why?

Back to article view | Back to comp.lang.python

Contents

  A simple single line, triple-quoted comment is giving syntax error. Why? Aditya Raj Bhatt <adityarajbhatt@gmail.com> - 2015-03-18 10:46 -0700
    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Laurent Pointal <laurent.pointal@laposte.net> - 2015-03-18 19:04 +0100
      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Laurent Pointal <laurent.pointal@laposte.net> - 2015-03-18 19:06 +0100
        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-18 20:53 +0100
          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-18 20:56 +0100
          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Terry Reedy <tjreedy@udel.edu> - 2015-03-18 17:47 -0400
          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-19 09:58 +1100
            Re: A simple single line, triple-quoted comment is giving syntax error. Why? Chris Angelico <rosuav@gmail.com> - 2015-03-19 10:23 +1100
      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Aditya Raj Bhatt <adityarajbhatt@gmail.com> - 2015-03-18 11:23 -0700
        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Igor Korot <ikorot01@gmail.com> - 2015-03-18 14:45 -0400
        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Laurent Pointal <laurent.pointal@laposte.net> - 2015-03-18 20:08 +0100
        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Tim Roberts <timr@probo.com> - 2015-03-28 16:34 -0700
    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-18 21:21 +0100
    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Tim Chase <python.list@tim.thechases.com> - 2015-03-18 13:15 -0500
    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ben Finney <ben+python@benfinney.id.au> - 2015-03-19 11:06 +1100
    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Denis McMahon <denismfmcmahon@gmail.com> - 2015-03-19 00:53 +0000
      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-22 04:14 +0100
        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Chris Angelico <rosuav@gmail.com> - 2015-03-22 14:36 +1100
          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-22 04:49 +0100
            Re: A simple single line, triple-quoted comment is giving syntax error. Why? Chris Angelico <rosuav@gmail.com> - 2015-03-22 15:11 +1100
              Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-26 05:35 +0100
                Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-25 23:09 -0600
                  Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-26 17:45 +0100
                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-26 12:29 -0600
                      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-26 19:54 +0100
                        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-26 17:27 -0600
                          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-28 19:20 +0100
                            Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-29 01:56 -0600
                              Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-29 12:41 +0200
                                Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-31 01:23 -0600
                                  Re: A simple single line, triple-quoted comment is giving syntax error. Why? sohcahtoa82@gmail.com - 2015-03-31 16:10 -0700
                                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Chris Angelico <rosuav@gmail.com> - 2015-04-01 10:36 +1100
                                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-31 17:43 -0600
                                  Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-02 23:31 +0200
                                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? sohcahtoa82@gmail.com - 2015-04-02 15:26 -0700
                                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-04-02 18:21 -0600
                                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-04-03 16:40 +1100
                                      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Chris Angelico <rosuav@gmail.com> - 2015-04-03 16:57 +1100
                                        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Marko Rauhamaa <marko@pacujo.net> - 2015-04-03 10:13 +0300
                                          r"\"" ??? (was A simple single line, triple-quoted comment) Rustom Mody <rustompmody@gmail.com> - 2015-04-03 05:52 -0700
                                            Re: r"\"" ??? (was A simple single line, triple-quoted comment) Chris Angelico <rosuav@gmail.com> - 2015-04-04 01:40 +1100
                                              Re: r"\"" ??? (was A simple single line, triple-quoted comment) Rustom Mody <rustompmody@gmail.com> - 2015-04-03 08:14 -0700
                                          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-04-03 09:25 -0600
                                      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-04-03 00:40 -0600
                      Re: A simple single line, triple-quoted comment is giving syntax   error. Why? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-03-27 11:43 +1300
                        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-28 19:06 +0100
                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-26 12:32 -0600
                      Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-26 19:56 +0100
                        Re: A simple single line, triple-quoted comment is giving syntax error. Why? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-27 10:15 +1100
                          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Tim Chase <python.list@tim.thechases.com> - 2015-03-26 18:47 -0500
                          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Ian Kelly <ian.g.kelly@gmail.com> - 2015-03-26 19:38 -0600
                          Re: A simple single line, triple-quoted comment is giving syntax error. Why? Marko Rauhamaa <marko@pacujo.net> - 2015-03-27 07:34 +0200
                Re: A simple single line, triple-quoted comment is giving syntax error. Why? Dave Angel <davea@davea.name> - 2015-03-26 01:23 -0400
                  Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-26 18:25 +0100
                    Re: A simple single line, triple-quoted comment is giving syntax error. Why? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-03-26 18:30 +0100
            Re: A simple single line, triple-quoted comment is giving syntax error. Why? Marko Rauhamaa <marko@pacujo.net> - 2015-03-22 12:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#88022

Chris Angelico wrote:

> On Sun, Mar 22, 2015 at 2:49 PM, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>>> Implicit concatenation is part of the syntax, not part of the expression
>>> evaluator.
>> Reads like nonsense to me.
> 
> What do you mean?

As I showed, string literals and consecutive tokens of string literals 
(“STRING+”) so as to do implicit concatenation *are* expressions of the 
Python grammar.  Expressions are *part of* the syntax of a programming 
language.

Perhaps you mean that the time when implicit concatenation is evaluated 
(compile time) differs from the time when other expressions are evaluated 
(runtime).  But a) whether that is true depends on the implementation and
b) there can be no doubt that either expression needs to be evaluated.  So 
whatever you mean by “expression evaluator” has to be able to do those 
things.

Which makes the statement above read like nonsense to me.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#88026

On Wed, Mar 25, 2015 at 10:35 PM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Chris Angelico wrote:
>
>> On Sun, Mar 22, 2015 at 2:49 PM, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>>>> Implicit concatenation is part of the syntax, not part of the expression
>>>> evaluator.
>>> Reads like nonsense to me.
>>
>> What do you mean?
>
> As I showed, string literals and consecutive tokens of string literals
> (“STRING+”) so as to do implicit concatenation *are* expressions of the
> Python grammar.  Expressions are *part of* the syntax of a programming
> language.
>
> Perhaps you mean that the time when implicit concatenation is evaluated
> (compile time) differs from the time when other expressions are evaluated
> (runtime).  But a) whether that is true depends on the implementation and
> b) there can be no doubt that either expression needs to be evaluated.  So
> whatever you mean by “expression evaluator” has to be able to do those
> things.
>
> Which makes the statement above read like nonsense to me.

What the grammar that you quoted from shows is that STRING+ is an
expression. The individual STRINGs of a STRING+ are not expressions,
except to the extent that they can be parsed in isolation as a
STRING+. By the same token, a STRING+ is a single string literal, not
an aggregate of several.

Ancillary data point:

>>> help(ast.literal_eval)
    Safely evaluate an expression node or a string containing a Python
    expression.  The string or node provided may only consist of the following
    Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
    sets, booleans, and None.
>>> ast.literal_eval('"foo" "bar"')
'foobar'

So the ast.literal_eval also treats this as one literal expression.

[toc] | [prev] | [next] | [standalone]

#88075

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Chris Angelico wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
>>>>> Implicit concatenation is part of the syntax, not part of the
>>>>> expression evaluator.
>>>> Reads like nonsense to me.
>>> What do you mean?
>> As I showed, string literals and consecutive tokens of string literals
>> (“STRING+”) so as to do implicit concatenation *are* expressions of the
>> Python grammar.  Expressions are *part of* the syntax of a programming
>> language.
>>
>> Perhaps you mean that the time when implicit concatenation is evaluated
>> (compile time) differs from the time when other expressions are evaluated
>> (runtime).  But a) whether that is true depends on the implementation and
>> b) there can be no doubt that either expression needs to be evaluated. 
>> So whatever you mean by “expression evaluator” has to be able to do those
>> things.
>>
>> Which makes the statement above read like nonsense to me.
> 
> What the grammar that you quoted from shows is that STRING+ is an
> expression. The individual STRINGs of a STRING+ are not expressions,
> except to the extent that they can be parsed in isolation as a
> STRING+.

How did you get that idea?  STRING+ means one or more consecutive STRING 
tokens (ignoring whitespace in-between), which means one or more consecutive 
string literals.  A (single) string literal definitely is an expression as 
it can be produced with the “expr” goal symbol of the Python grammar (given 
there in a flavor of EBNF).

> By the same token, a STRING+ is a single string literal, not
> an aggregate of several.

No, 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*.

<http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form> pp.

> Ancillary data point:
> 
> >>> help(ast.literal_eval)
>     Safely evaluate an expression node or a string containing a Python
>     expression.  The string or node provided may only consist of the 
>     following Python literal structures: strings, bytes, numbers, tuples, 
>     lists, dicts, sets, booleans, and None.
> >>> ast.literal_eval('"foo" "bar"')
> 'foobar'
> 
> So the ast.literal_eval also treats this as one literal expression.

What do you mean?

ast.literal_eval() sees a single string value resulting from the evaluation 
of one string literal, by the Python compiler, that contains the 
representation of two consecutive string literals:

  '"foo" "bar"'

It then does exactly what the Python compiler would do in such a case: parse 
this as if it were one string literal (the “implicit concatenation” I am 
talking about).

  "foo" "bar" ≡ "foobar"

This was not debated.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#88082

On Thu, Mar 26, 2015 at 10:45 AM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Ian Kelly wrote:
>> What the grammar that you quoted from shows is that STRING+ is an
>> expression. The individual STRINGs of a STRING+ are not expressions,
>> except to the extent that they can be parsed in isolation as a
>> STRING+.
>
> How did you get that idea?  STRING+ means one or more consecutive STRING
> tokens (ignoring whitespace in-between), which means one or more consecutive
> string literals.  A (single) string literal definitely is an expression as
> it can be produced with the “expr” goal symbol of the Python grammar (given
> there in a flavor of EBNF).

Yes, that's what I was referring to in my parenthetical "except..." above.

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

Not like this:

    expr
     |
   STRING+
    /  \
 expr  expr
  |      |
STRING  STRING

There is only one expr node, and it contains both STRING tokens.

>> By the same token, a STRING+ is a single string literal, not
>> an aggregate of several.
>
> No, 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.

[toc] | [prev] | [next] | [standalone]

#88084

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Ian Kelly wrote:
>>> What the grammar that you quoted from shows is that STRING+ is an
>>> expression. The individual STRINGs of a STRING+ are not expressions,
>>> except to the extent that they can be parsed in isolation as a
>>> STRING+.
>> How did you get that idea?  STRING+ means one or more consecutive STRING
>> tokens (ignoring whitespace in-between), which means one or more
>> consecutive string literals.  A (single) string literal definitely is an 
>> expression as it can be produced with the “expr” goal symbol of the 
>> Python grammar (given there in a flavor of EBNF).
> 
> Yes, that's what I was referring to in my parenthetical "except..." above.

Your “except” is contradictory to the rest of what you said, at best.

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

But be warned: Neither would prove that a string literal is not an 
expression.  Because you did not consider the most simple variant of an AST 
(or subtree) according to this grammar:

    expr
     |
   STRING

Again, “STRING+” does _not_ mean “STRING STRING STRING*”; it means “STRING 
STRING*”.  The second and following STRINGs are *optional*.

>> […] 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.)  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).
 
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#88108

On Thu, Mar 26, 2015 at 12:54 PM, Thomas 'PointedEars' Lahn
<PointedEars@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.

[toc] | [prev] | [next] | [standalone]

#88234

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] 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.

And why should you?  That is not what you claimed.

> If you believe otherwise, show a parse tree that parses these as
> separate expressions.

Fallacies: Straw man, shifting the burden of proof.

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

Yes, you did.  You debated my statement which says that.  Let me refresh 
your memory.  I said:

| As I showed, string literals and consecutive tokens of string literals 
| (“STRING+”) so as to do implicit concatenation *are* expressions of the 
| Python grammar.

To which you replied:

| What the grammar that you quoted from shows is that STRING+ is an
| expression. The individual STRINGs of a STRING+ are not expressions, […]
                             ^^^^^^^              ^^^^^^^^^^^^^^^^^^^
You continued with

| except to the extent that they can be parsed in isolation as a STRING+.

but that is nothing more than a backdoor, contradictory to what you said 
before (and, as it has been showed, nonsensical).

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

Then you must have fundamentally misunderstood my statement and this whole 
discussion.

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

Actually, you were arguing against my statement that string literals are 
expressions (that a string literal is an expression).  You claimed, rather 
explicitly, that they were not.  See above.

>> 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 am not speaking down to you.  But the fact needed to be emphasized that 
you could not have been reading carefully what I wrote.

> I'm quite familiar with basic concepts of EBNF.

But apparently not logic.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#88249

On Sat, Mar 28, 2015 at 12:20 PM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Ian Kelly wrote:
>
>> […] Thomas 'PointedEars' Lahn […] 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.
>
> And why should you?  That is not what you claimed.

Of course it is. I claimed that there was only one expr node in the
parse tree of "foo" "bar". You asked me to prove it. That would
require two things: first, showing that the complete expansion of the
parse tree above does not include any further expr nodes (which I
contend is obvious enough that it should not need to be explicitly
spelled out in this thread), and second, showing that no other parse
tree will generate "foo" "bar".

>> If you believe otherwise, show a parse tree that parses these as
>> separate expressions.
>
> Fallacies: Straw man, shifting the burden of proof.

If there is a straw man here, it is only the result of one or both of
us failing to communicate. Are you now saying that you agree that
there is only one expr node in the parse of "foo" "bar"? If so, then
why did you ask me to prove it?

Why should the burden of proof be on me in the first place? I made the
request because demonstrating the positive (such a parse tree exists)
would, as usual, be much simpler than proving the negative (no such
parse tree exists).

In any case, it sounds to me like we're probably in agreement at this point.

>>> 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.
>
> Yes, you did.  You debated my statement which says that.  Let me refresh
> your memory.  I said:

You are correct. I was reading "string literal" as STRING+ when I
wrote that. I was perhaps confused because your statement "Neither
would prove that a string literal is not an expression" did not make
sense to me at the time.

Within a grammar, the question of "is an X a Y" is nonsensical in
isolation. It can only be answered in relation to a parse tree.
Consider the simple grammar:

S -> A | B
A -> x
B -> x

Is x an A? It depends. If the tree that generates the x produces it
from an A node, then yes. Otherwise, no.

So when I write that the "foo" in "foo" "bar" is not an expression, I
am only speaking in relation to the parse tree that generates "foo"
"bar". I am not speaking about the parse tree that generates only
"foo", because it is irrelevant, even though in that context it would
be an expression.

> | As I showed, string literals and consecutive tokens of string literals
> | (“STRING+”) so as to do implicit concatenation *are* expressions of the
> | Python grammar.
>
> To which you replied:
>
> | What the grammar that you quoted from shows is that STRING+ is an
> | expression. The individual STRINGs of a STRING+ are not expressions, […]
>                              ^^^^^^^              ^^^^^^^^^^^^^^^^^^^
> You continued with
>
> | except to the extent that they can be parsed in isolation as a STRING+.
>
> but that is nothing more than a backdoor, contradictory to what you said
> before (and, as it has been showed, nonsensical).

I don't know what you mean by a "backdoor". The purpose of that
parenthetical was to explicitly acknowledge that the single STRING
could be viewed as an expression when taken out of context, and to
disclaim that I was excluding that case from the preceding statement.
I still stand by that statement; The "foo" in "foo" "bar" is not an
expression in the same sense that the "42" is not an expression in
"hucr,.@#%c|42ptqc$".

>> 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.
>
> Then you must have fundamentally misunderstood my statement and this whole
> discussion.

Quite possibly. Rereading the thread at the point where I jumped in,
it's not clear to me now what it was in your post that I was
responding to.

>> 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.
>
> Actually, you were arguing against my statement that string literals are
> expressions (that a string literal is an expression).  You claimed, rather
> explicitly, that they were not.  See above.

I have no idea what point you're trying to convey here.

>> I'm quite familiar with basic concepts of EBNF.
>
> But apparently not logic.

Are you intentionally trying to be inflammatory? I think that I have
misunderstood your writing in places and that you have likewise
misunderstood mine in others. Can we leave it at that?

[toc] | [prev] | [next] | [standalone]

#88257

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Ian Kelly wrote:
>>> […] Thomas 'PointedEars' Lahn […] 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.
>>
>> And why should you?  That is not what you claimed.
> 
> Of course it is. I claimed that there was only one expr node in the
> parse tree of "foo" "bar".

Which is something else.

> That would require two things: […]

What I asked you would require only a real-life representation of the parse 
tree above.

>>> If you believe otherwise, show a parse tree that parses these as
>>> separate expressions.
>> Fallacies: Straw man, shifting the burden of proof.
> 
> If there is a straw man here, it is only the result of one or both of
> us failing to communicate.

I agree.

> If so, then why did you ask me to prove it?

See above.

> Why should the burden of proof be on me in the first place?

Because *you* made the claim that “STRING+” could be part of an AST in this 
way.

> In any case, it sounds to me like we're probably in agreement at this
> point.

I do not think so.

> Within a grammar, the question of "is an X a Y" is nonsensical in
> isolation. It can only be answered in relation to a parse tree.
> Consider the simple grammar:
> 
> S -> A | B
> A -> x
> B -> x
> 
> Is x an A? It depends.

No, by the definition 2 below, that we all accepted implicitly up to this 
point, x is *definitely* an A.

> If the tree that generates the x produces it from an A node, then yes. 
> Otherwise, no.

Fallacy.

First, two definitions, so that we are clear what we are talking about:

(1) Let a *production chain* be the repeated application of the production   
    rules of a formal grammar such that

      C ⇒ D ⇒ x

    is a production chain if there are production rules

      C → D
      D → x.

    [Note the difference between “⇒” and “→”.]

(2) Let the statement “x is an A” be true if x can be produced in a
    production chain starting with or including the non-terminal A
    left-hand side –

      x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).

Now, according to these definitions, in the offered grammar x is *both* an A 
and a B.  Because what matters is _not_ the practical result of production 
chains (the actual parse tree), but the certainty of the theoretical 
possibility of it.

However, in the interest of disambiguity in their parsers, programming 
languages do not have such a set of production rules in their grammar that 
lead to ambiguous productions.  In particular, you will not find in the 
Python grammar another production rule that leads to “STRING” being 
producable by a production chain not containing “expr”.

So, if we accept these definitions, we can and have to extend the 
classification of STRING( literals) to say that they are “atom”s, 
“arith(metic)_expr”(ession)s (as strange as that may sound), and so on, 
“expr”(ession)s, “comparison”s and so on (as strange as that may sound),
and finally “st(ate)m(en)t”s (this fact started the whole discussion),
and “single_input”s, and not anything else.

> So when I write that the "foo" in "foo" "bar" is not an expression, I
> am only speaking in relation to the parse tree that generates "foo"
> "bar".

But it has been indicated by others that the parse tree that you presented 
is wrong, based on a misconception about the syntax of the formal grammar, 
and you have not yet substantiated your claim that it is correct.

> I am not speaking about the parse tree that generates only
> "foo", because it is irrelevant, even though in that context it would
> be an expression.

Same fallacy as above.

> I don't know what you mean by a "backdoor".

Appending a statement that is contradictory to what was stated just before, 
or at least ambiguous, so that the possibility arises for one to say “I did 
not mean that” when that/a contradiction to the former statement is pointed 
out later.

> The purpose of that parenthetical was to explicitly acknowledge that the 
> single STRING could be viewed as an expression when taken out of context,

Yes, your fallacy is mainly based on ignoring the context.  Context is 
important; you cannot just ignore it and still make correct arguments.

> and to disclaim that I was excluding that case from the preceding 
> statement. I still stand by that statement; The "foo" in "foo" "bar" is 
> not an expression in the same sense that the "42" is not an expression in
> "hucr,.@#%c|42ptqc$".

False analogy.  The “42” in there cannot be produced by “expr” *in that 
context* (it can only be produced by “STRING”).

>> Actually, you were arguing against my statement that string literals are
>> expressions (that a string literal is an expression).  You claimed,
>> rather explicitly, that they were not.  See above.
> 
> I have no idea what point you're trying to convey here.

Is the “See above” not enough a reference?

>>> I'm quite familiar with basic concepts of EBNF.
>> But apparently not logic.
> 
> Are you intentionally trying to be inflammatory?

I am merely stating my observations.  There is no offense where none is 
taken.

> I think that I have misunderstood your writing in places and that you have 
> likewise misunderstood mine in others. Can we leave it at that?

No, because misunderstandings need to be clarified and fallacies need to be 
exposed if we are to arrive at the truth.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#88368

On Sun, Mar 29, 2015 at 4:41 AM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Ian Kelly wrote:
>
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Ian Kelly wrote:
>> Why should the burden of proof be on me in the first place?
>
> Because *you* made the claim that “STRING+” could be part of an AST in this
> way.

Okay, I didn't understand before that this was the part that you were
objecting to. I had written "There is only one expr node, and it
contains both STRING tokens", to which you replied "Prove it." I did
not intend to imply anything at all by the inclusion of STRING+ in the
tree. That pseudo-tree was hastily sketched out, and as both you and
Gregory have pointed out, STRING+ is not a symbol of the grammar and
should not have been included as a node. None of this has any bearing
on what I was trying to demonstrate with that tree.

>> Within a grammar, the question of "is an X a Y" is nonsensical in
>> isolation. It can only be answered in relation to a parse tree.
>> Consider the simple grammar:
>>
>> S -> A | B
>> A -> x
>> B -> x
>>
>> Is x an A? It depends.
>
> No, by the definition 2 below, that we all accepted implicitly up to this
> point, x is *definitely* an A.

What gives you the impression that I ever accepted it?

>> If the tree that generates the x produces it from an A node, then yes.
>> Otherwise, no.
>
> Fallacy.
>
> First, two definitions, so that we are clear what we are talking about:
>
> (1) Let a *production chain* be the repeated application of the production
>     rules of a formal grammar such that
>
>       C ⇒ D ⇒ x
>
>     is a production chain if there are production rules
>
>       C → D
>       D → x.
>
>     [Note the difference between “⇒” and “→”.]

Sure.

> (2) Let the statement “x is an A” be true if x can be produced in a
>     production chain starting with or including the non-terminal A
>     left-hand side –
>
>       x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).

Sorry, but this definition just seems entirely arbitrary to me.
Mathematically, it looks nonsensical; A is a symbol, not a set. This
question of whether "x is an A" is informal and not a topic of formal
language theory so far as I'm aware. Can you cite some source for it?

> Now, according to these definitions, in the offered grammar x is *both* an A
> and a B.  Because what matters is _not_ the practical result of production
> chains (the actual parse tree), but the certainty of the theoretical
> possibility of it.

This strikes me as being a lot like arguing, "some kites are toys, and
some kites are birds; therefore, all kites are both toys and birds."

>> So when I write that the "foo" in "foo" "bar" is not an expression, I
>> am only speaking in relation to the parse tree that generates "foo"
>> "bar".
>
> But it has been indicated by others that the parse tree that you presented
> is wrong, based on a misconception about the syntax of the formal grammar,
> and you have not yet substantiated your claim that it is correct.

As noted above, the inaccuracy that Gregory pointed out has no bearing
on my argument.

You're really going to make me spell it out, aren't you? Fine, here you go.

single_input -> simple_stmt -> expr_stmt -> testlist_star_expr -> test
-> or_test -> and_test -> not_test -> comparison -> expr -> xor_expr
-> and_expr -> shift_expr -> arith_expr -> term -> factor -> power ->
atom -> STRING STRING

Note: the derivation contains exactly one expr node, which indirectly
produces both STRINGs. Neither STRING in this derivation is
individually produced from the expr.

>> I don't know what you mean by a "backdoor".
>
> Appending a statement that is contradictory to what was stated just before,
> or at least ambiguous, so that the possibility arises for one to say “I did
> not mean that” when that/a contradiction to the former statement is pointed
> out later.

The purpose was not to make the possibility arise to say that. The
purpose was to point out the discontinuity *immediately* so that it
would be already addressed and not *need* to be pointed out later
(although we can see how well that turned out).

I have to say that I find it highly surprising that you find this
construction objectionable. Would you still consider it
"contradictory" if I had phrased it equivalently as a logical "or"
rather than using the word "except"?

>> The purpose of that parenthetical was to explicitly acknowledge that the
>> single STRING could be viewed as an expression when taken out of context,
>
> Yes, your fallacy is mainly based on ignoring the context.  Context is
> important; you cannot just ignore it and still make correct arguments.

Funny, I thought that was my line. This whole argument came about
because you seem to be stubbornly insistent on ignoring the context
that I set for my statement, calling it "contradictory" instead.

>> and to disclaim that I was excluding that case from the preceding
>> statement. I still stand by that statement; The "foo" in "foo" "bar" is
>> not an expression in the same sense that the "42" is not an expression in
>> "hucr,.@#%c|42ptqc$".
>
> False analogy.  The “42” in there cannot be produced by “expr” *in that
> context* (it can only be produced by “STRING”).

I apologize for the confusion. The quotation marks there were only
intended to separate the nonsense construction from my own text, not
as string delimiters. I realize that in the first part of the analogy
I did use them as string delimiters, so I was inconsistent.

The analogy to be drawn is that a parse tree of ⟨"foo" "bar"⟩ that
contains an expr node for each STRING is an invalid parse, just as a
parse tree of ⟨hucr,.@#%c|42ptqc$⟩ that isolates ⟨42⟩ as a single expr
(or any other parse tree in this particular case) is invalid.

>>> Actually, you were arguing against my statement that string literals are
>>> expressions (that a string literal is an expression).  You claimed,
>>> rather explicitly, that they were not.  See above.
>>
>> I have no idea what point you're trying to convey here.
>
> Is the “See above” not enough a reference?

I get the connection between what you wrote here and what you wrote
above. I don't get the connection between what I wrote (that has now
been trimmed away) and what you wrote in response to it. My
parenthetical about parsing STRINGs in isolation was not in itself an
argument against what you wrote. It was in fact agreeing, within a
limited context.

[toc] | [prev] | [next] | [standalone]

#88405

On Tuesday, March 31, 2015 at 12:24:53 AM UTC-7, Ian wrote:
> On Sun, Mar 29, 2015 at 4:41 AM, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> > Ian Kelly wrote:
> >
> >> […] Thomas 'PointedEars' Lahn […] wrote:
> >>> Ian Kelly wrote:
> >> Why should the burden of proof be on me in the first place?
> >
> > Because *you* made the claim that “STRING+” could be part of an AST in this
> > way.
> 
> Okay, I didn't understand before that this was the part that you were
> objecting to. I had written "There is only one expr node, and it
> contains both STRING tokens", to which you replied "Prove it." I did
> not intend to imply anything at all by the inclusion of STRING+ in the
> tree. That pseudo-tree was hastily sketched out, and as both you and
> Gregory have pointed out, STRING+ is not a symbol of the grammar and
> should not have been included as a node. None of this has any bearing
> on what I was trying to demonstrate with that tree.
> 
> >> Within a grammar, the question of "is an X a Y" is nonsensical in
> >> isolation. It can only be answered in relation to a parse tree.
> >> Consider the simple grammar:
> >>
> >> S -> A | B
> >> A -> x
> >> B -> x
> >>
> >> Is x an A? It depends.
> >
> > No, by the definition 2 below, that we all accepted implicitly up to this
> > point, x is *definitely* an A.
> 
> What gives you the impression that I ever accepted it?
> 
> >> If the tree that generates the x produces it from an A node, then yes.
> >> Otherwise, no.
> >
> > Fallacy.
> >
> > First, two definitions, so that we are clear what we are talking about:
> >
> > (1) Let a *production chain* be the repeated application of the production
> >     rules of a formal grammar such that
> >
> >       C ⇒ D ⇒ x
> >
> >     is a production chain if there are production rules
> >
> >       C → D
> >       D → x.
> >
> >     [Note the difference between “⇒” and “→”.]
> 
> Sure.
> 
> > (2) Let the statement “x is an A” be true if x can be produced in a
> >     production chain starting with or including the non-terminal A
> >     left-hand side –
> >
> >       x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).
> 
> Sorry, but this definition just seems entirely arbitrary to me.
> Mathematically, it looks nonsensical; A is a symbol, not a set. This
> question of whether "x is an A" is informal and not a topic of formal
> language theory so far as I'm aware. Can you cite some source for it?
> 
> > Now, according to these definitions, in the offered grammar x is *both* an A
> > and a B.  Because what matters is _not_ the practical result of production
> > chains (the actual parse tree), but the certainty of the theoretical
> > possibility of it.
> 
> This strikes me as being a lot like arguing, "some kites are toys, and
> some kites are birds; therefore, all kites are both toys and birds."
> 
> >> So when I write that the "foo" in "foo" "bar" is not an expression, I
> >> am only speaking in relation to the parse tree that generates "foo"
> >> "bar".
> >
> > But it has been indicated by others that the parse tree that you presented
> > is wrong, based on a misconception about the syntax of the formal grammar,
> > and you have not yet substantiated your claim that it is correct.
> 
> As noted above, the inaccuracy that Gregory pointed out has no bearing
> on my argument.
> 
> You're really going to make me spell it out, aren't you? Fine, here you go.
> 
> single_input -> simple_stmt -> expr_stmt -> testlist_star_expr -> test
> -> or_test -> and_test -> not_test -> comparison -> expr -> xor_expr
> -> and_expr -> shift_expr -> arith_expr -> term -> factor -> power ->
> atom -> STRING STRING
> 
> Note: the derivation contains exactly one expr node, which indirectly
> produces both STRINGs. Neither STRING in this derivation is
> individually produced from the expr.
> 
> >> I don't know what you mean by a "backdoor".
> >
> > Appending a statement that is contradictory to what was stated just before,
> > or at least ambiguous, so that the possibility arises for one to say “I did
> > not mean that” when that/a contradiction to the former statement is pointed
> > out later.
> 
> The purpose was not to make the possibility arise to say that. The
> purpose was to point out the discontinuity *immediately* so that it
> would be already addressed and not *need* to be pointed out later
> (although we can see how well that turned out).
> 
> I have to say that I find it highly surprising that you find this
> construction objectionable. Would you still consider it
> "contradictory" if I had phrased it equivalently as a logical "or"
> rather than using the word "except"?
> 
> >> The purpose of that parenthetical was to explicitly acknowledge that the
> >> single STRING could be viewed as an expression when taken out of context,
> >
> > Yes, your fallacy is mainly based on ignoring the context.  Context is
> > important; you cannot just ignore it and still make correct arguments.
> 
> Funny, I thought that was my line. This whole argument came about
> because you seem to be stubbornly insistent on ignoring the context
> that I set for my statement, calling it "contradictory" instead.
> 
> >> and to disclaim that I was excluding that case from the preceding
> >> statement. I still stand by that statement; The "foo" in "foo" "bar" is
> >> not an expression in the same sense that the "42" is not an expression in
> >> "hucr,.@#%c|42ptqc$".
> >
> > False analogy.  The “42” in there cannot be produced by “expr” *in that
> > context* (it can only be produced by “STRING”).
> 
> I apologize for the confusion. The quotation marks there were only
> intended to separate the nonsense construction from my own text, not
> as string delimiters. I realize that in the first part of the analogy
> I did use them as string delimiters, so I was inconsistent.
> 
> The analogy to be drawn is that a parse tree of ⟨"foo" "bar"⟩ that
> contains an expr node for each STRING is an invalid parse, just as a
> parse tree of ⟨hucr,.@#%c|42ptqc$⟩ that isolates ⟨42⟩ as a single expr
> (or any other parse tree in this particular case) is invalid.
> 
> >>> Actually, you were arguing against my statement that string literals are
> >>> expressions (that a string literal is an expression).  You claimed,
> >>> rather explicitly, that they were not.  See above.
> >>
> >> I have no idea what point you're trying to convey here.
> >
> > Is the “See above” not enough a reference?
> 
> I get the connection between what you wrote here and what you wrote
> above. I don't get the connection between what I wrote (that has now
> been trimmed away) and what you wrote in response to it. My
> parenthetical about parsing STRINGs in isolation was not in itself an
> argument against what you wrote. It was in fact agreeing, within a
> limited context.

Holy hell, dude, you've been arguing about this for nearly two weeks now.

Let it go.

[toc] | [prev] | [next] | [standalone]

#88406

On Wed, Apr 1, 2015 at 10:10 AM,  <sohcahtoa82@gmail.com> wrote:
> Holy hell, dude, you've been arguing about this for nearly two weeks now.
>
> Let it go.

Not sure you understand the nature of language debates. They can't
hold it back any more!

ChrisA

[toc] | [prev] | [next] | [standalone]

#88407

[Multipart message — attachments visible in raw view] — view raw

On Mar 31, 2015 5:16 PM, <sohcahtoa82@gmail.com> wrote:
> Holy hell, dude, you've been arguing about this for nearly two weeks now.
>
> Let it go.

That's rather an exaggeration. I've made seven posts to this thread up
until now, the first of which was six days ago, not two weeks. I don't
think that's excessive.

I suggested dropping it a couple of posts back, but Thomas seemed
interested in continuing to seek clarity, which I have no objection to.

[toc] | [prev] | [next] | [standalone]

#88461

Ian Kelly wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Ian Kelly wrote:
>>> Within a grammar, the question of "is an X a Y" is nonsensical in
>>> isolation. It can only be answered in relation to a parse tree.
>>> Consider the simple grammar:
>>>
>>> S -> A | B
>>> A -> x
>>> B -> x
>>>
>>> Is x an A? It depends.
>>
>> No, by the definition 2 below, that we all accepted implicitly up to this
>> point, x is *definitely* an A.
> 
> What gives you the impression that I ever accepted it?

,-<news:mailman.181.1427346636.10327.python-list@python.org>
| 
| What the grammar that you quoted from shows is that STRING+ is an
| expression.

There is *no way* for you to make that statement if you did not accept 
definition (2).

>> (2) Let the statement “x is an A” be true if x can be produced in a
>>     production chain starting with or including the non-terminal A
>>     left-hand side –
>>
>>       x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).
> 
> Sorry, but this definition just seems entirely arbitrary to me.

It is just the formalization of the definition that we all have agreed to, 
including you.

> Mathematically, it looks nonsensical; A is a symbol, not a set.

“A” is the goal symbol of a production, so it can be interpreted as the 
superset of all set of terminals that can be produced from it, through the 
goal symbols that can be produced from it.  And all of us implicitly did 
that when we said “STRING(+) (literals) is/are (not) (an) expression(s)”.

> This question of whether "x is an A" is informal and not a topic of formal
> language theory so far as I'm aware. Can you cite some source for it?

No, because I was formalizing the ad-hoc definition by Chris Angelico in 
<news:mailman.51.1426995416.10327.python-list@python.org>.

>> Now, according to these definitions, in the offered grammar x is *both*
>> an A and a B.  Because what matters is _not_ the practical result of
>> production chains (the actual parse tree), but the certainty of the
>> theoretical possibility of it.
> 
> This strikes me as being a lot like arguing, "some kites are toys, and
> some kites are birds; therefore, all kites are both toys and birds."

False analogy again.  We are discussing *in theory* a *formal* grammar.  Its 
goal symbols have *no meaning* except what can be produced from them.

> As noted above, the inaccuracy that Gregory pointed out has no bearing
> on my argument.

But it does.

> You're really going to make me spell it out, aren't you? Fine, here you
> go.
> 
> single_input -> […] -> expr -> […] -> atom -> STRING STRING
> 
> Note: the derivation contains exactly one expr node, which indirectly
> produces both STRINGs. Neither STRING in this derivation is
> individually produced from the expr.

So you have proven that which nobody ever doubted nor requested, but I 
pointed out already.  What you have still not proven is what you claimed: 
the parse tree.

I am sorry that you cannot see that your argument is strewn with gaping 
defects in logic, but I think I will stop trying to convince you of that 
now.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#88462

On Thursday, April 2, 2015 at 2:33:17 PM UTC-7, Thomas 'PointedEars' Lahn wrote:
> Ian Kelly wrote:
> 
> > […] Thomas 'PointedEars' Lahn […] wrote:
> >> Ian Kelly wrote:
> >>> Within a grammar, the question of "is an X a Y" is nonsensical in
> >>> isolation. It can only be answered in relation to a parse tree.
> >>> Consider the simple grammar:
> >>>
> >>> S -> A | B
> >>> A -> x
> >>> B -> x
> >>>
> >>> Is x an A? It depends.
> >>
> >> No, by the definition 2 below, that we all accepted implicitly up to this
> >> point, x is *definitely* an A.
> > 
> > What gives you the impression that I ever accepted it?
> 
> ,-<news:mailman.181.1427346636.10327.python-list@python.org>
> | 
> | What the grammar that you quoted from shows is that STRING+ is an
> | expression.
> 
> There is *no way* for you to make that statement if you did not accept 
> definition (2).
> 
> >> (2) Let the statement “x is an A” be true if x can be produced in a
> >>     production chain starting with or including the non-terminal A
> >>     left-hand side –
> >>
> >>       x ∈ A ↔ ∃A (… ⇒ A ⇒ … ⇒ x).
> > 
> > Sorry, but this definition just seems entirely arbitrary to me.
> 
> It is just the formalization of the definition that we all have agreed to, 
> including you.
> 
> > Mathematically, it looks nonsensical; A is a symbol, not a set.
> 
> “A” is the goal symbol of a production, so it can be interpreted as the 
> superset of all set of terminals that can be produced from it, through the 
> goal symbols that can be produced from it.  And all of us implicitly did 
> that when we said “STRING(+) (literals) is/are (not) (an) expression(s)”.
> 
> > This question of whether "x is an A" is informal and not a topic of formal
> > language theory so far as I'm aware. Can you cite some source for it?
> 
> No, because I was formalizing the ad-hoc definition by Chris Angelico in 
> <news:mailman.51.1426995416.10327.python-list@python.org>.
> 
> >> Now, according to these definitions, in the offered grammar x is *both*
> >> an A and a B.  Because what matters is _not_ the practical result of
> >> production chains (the actual parse tree), but the certainty of the
> >> theoretical possibility of it.
> > 
> > This strikes me as being a lot like arguing, "some kites are toys, and
> > some kites are birds; therefore, all kites are both toys and birds."
> 
> False analogy again.  We are discussing *in theory* a *formal* grammar.  Its 
> goal symbols have *no meaning* except what can be produced from them.
> 
> > As noted above, the inaccuracy that Gregory pointed out has no bearing
> > on my argument.
> 
> But it does.
> 
> > You're really going to make me spell it out, aren't you? Fine, here you
> > go.
> > 
> > single_input -> […] -> expr -> […] -> atom -> STRING STRING
> > 
> > Note: the derivation contains exactly one expr node, which indirectly
> > produces both STRINGs. Neither STRING in this derivation is
> > individually produced from the expr.
> 
> So you have proven that which nobody ever doubted nor requested, but I 
> pointed out already.  What you have still not proven is what you claimed: 
> the parse tree.
> 
> I am sorry that you cannot see that your argument is strewn with gaping 
> defects in logic, but I think I will stop trying to convince you of that 
> now.
> 
> -- 
> PointedEars
> 
> Twitter: @PointedEars2
> Please do not cc me. / Bitte keine Kopien per E-Mail.

*sigh*

https://xkcd.com/386/

[toc] | [prev] | [next] | [standalone]

#88467

On Thu, Apr 2, 2015 at 3:31 PM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Ian Kelly wrote:
>
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Ian Kelly wrote:
>>>> Within a grammar, the question of "is an X a Y" is nonsensical in
>>>> isolation. It can only be answered in relation to a parse tree.
>>>> Consider the simple grammar:
>>>>
>>>> S -> A | B
>>>> A -> x
>>>> B -> x
>>>>
>>>> Is x an A? It depends.
>>>
>>> No, by the definition 2 below, that we all accepted implicitly up to this
>>> point, x is *definitely* an A.
>>
>> What gives you the impression that I ever accepted it?
>
> ,-<news:mailman.181.1427346636.10327.python-list@python.org>
> |
> | What the grammar that you quoted from shows is that STRING+ is an
> | expression.
>
> There is *no way* for you to make that statement if you did not accept
> definition (2).

Actually, there is a very simple way: I was being sloppily imprecise
when I wrote that.  First, I was speaking only in reference to the
class of parse trees with more than one STRING, as that was the topic
under discussion. I should have been clearer about that. Second, I
never should have used the term "STRING+" there (or anywhere else in
this discussion), as that merely clouded the point I was trying to
offer. What I *meant* was that the complete sequence of produced
STRINGs -- as opposed to any individual STRING -- is an expression,
and I inappropriately used "STRING+" to denote that. (Maybe that is
the point you were trying to make when you were talking about EBNF
before.)

>> This question of whether "x is an A" is informal and not a topic of formal
>> language theory so far as I'm aware. Can you cite some source for it?
>
> No, because I was formalizing the ad-hoc definition by Chris Angelico in
> <news:mailman.51.1426995416.10327.python-list@python.org>.

That URI is not useful to me as I don't use a newsreader. Is that the
message dated Sun, 22 Mar 2015 14:36:48 +1100? I don't see any
suggestion of this definition in that post.

t>>> Now, according to these definitions, in the offered grammar x is *both*
>>> an A and a B.  Because what matters is _not_ the practical result of
>>> production chains (the actual parse tree), but the certainty of the
>>> theoretical possibility of it.
>>
>> This strikes me as being a lot like arguing, "some kites are toys, and
>> some kites are birds; therefore, all kites are both toys and birds."
>
> False analogy again.  We are discussing *in theory* a *formal* grammar.  Its
> goal symbols have *no meaning* except what can be produced from them.

We're discussing a formal grammar as if it described a classification
hierarchy, which gives meaning to statements like "A STRING is an
expr". Otherwise, that statement is meaningless and can be neither
true nor false. So I think that the analogy between one such hierarchy
and another is apt.

>> You're really going to make me spell it out, aren't you? Fine, here you
>> go.
>>
>> single_input -> […] -> expr -> […] -> atom -> STRING STRING
>>
>> Note: the derivation contains exactly one expr node, which indirectly
>> produces both STRINGs. Neither STRING in this derivation is
>> individually produced from the expr.
>
> So you have proven that which nobody ever doubted nor requested, but I
> pointed out already.

As I tried to point out several posts back when I suggested that we
were in agreement, and which you flatly denied.

> What you have still not proven is what you claimed:
> the parse tree.

Because you misunderstood my claim.

[toc] | [prev] | [next] | [standalone]

#88470

On Friday 03 April 2015 08:31, Thomas 'PointedEars' Lahn wrote:

> I am sorry that you cannot see that your argument is strewn with gaping
> defects in logic, but I think I will stop trying to convince you of that
> now.

I'm sorry, I've been away for four days and have lost track of this thread. 
Have you reached an agreement about the number of angels which dance on the 
head of a pin yet, or will this argument continue for another week?

This sterile, pointless arguing about the minutia of pedantic definitions is 
not even close to useful. Honestly Thomas, Ian, nobody cares any more. If I 
were a betting man, I'd bet that neither of you can describe, in one 
sentence, what is the actual disagreement between the two of you, let alone 
why it matters for Python programming.


-- 
Steve

[toc] | [prev] | [next] | [standalone]

#88471

On Fri, Apr 3, 2015 at 4:40 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> This sterile, pointless arguing about the minutia of pedantic definitions is
> not even close to useful. Honestly Thomas, Ian, nobody cares any more. If I
> were a betting man, I'd bet that neither of you can describe, in one
> sentence, what is the actual disagreement between the two of you, let alone
> why it matters for Python programming.

I know that it started in response to my statement that string literal
concatenation wasn't an expression as such, but I have no idea what
either side of the current debate is, nor how it affects my
statement's validity. I _had_ hoped it would reach some sort of
conclusion - I may be right, I may be wrong, but it'd be nice to know
which. So far... no idea.

ChrisA

[toc] | [prev] | [next] | [standalone]

#88475

Chris Angelico <rosuav@gmail.com>:

> I know that it started in response to my statement that string literal
> concatenation wasn't an expression as such, but I have no idea what
> either side of the current debate is, nor how it affects my
> statement's validity.

This is what I have gathered:

 - A Python expression cannot directly follow another expression. A
   connector is required by the syntax.

 - That's untrue:
    * "abc"  is an expression
    * "def"  is an expression
    * "abc" "def"  is an expression
   QED

 - Merging "abc" "def" is a matter of lexical analysis.

 - No, it's right there in the syntax definition.

 - Well, ok, however, the parse tree for "abc" "def" is not

   expr:
     expr:
       atom:
         string: "abc"
     expr:
       atom:
         string: "def"

   Rather, the correct parse tree is:

   expr:
     expr:
       atom:
         string: "abc"
         string: "def"

   Thus, a Python expression still is not directly following another
   expression.


My own take: all sides are correct. Thomas is most correct and is being
obnoxious about it.

 1. A lexical analyzer *could* take care of concatenating string
    literals. It would have to be smart enough to handle intervening
    comments. On the other hand, the lexical analyzer is just a part of
    the parser; the line between them often is blurred.

 2. The counterexample "abc" "def" *does* demonstrate that expressions
    can at times follow each other immediately. It is a nice point even
    if not all that consequential.

    Somewhat analogously:
     * ord  is an expression
     * ("a")  is an expression
     * ord("a")  is an expression

 3. Arguing about definitions is silly. Is 0 a natural number? Is 1 a
    prime number?


Marko

[toc] | [prev] | [next] | [standalone]

#88481 — r"\"" ??? (was A simple single line, triple-quoted comment)

On Friday, April 3, 2015 at 12:43:32 PM UTC+5:30, Marko Rauhamaa wrote:
>  3. Arguing about definitions is silly. Is 0 a natural number? Is 1 a
>     prime number?

Speaking about silliness of definitions, I was knocked out in class by this today:

>>> r"\""
'\\"'

Seeing the docs
https://docs.python.org/3.4/reference/lexical_analysis.html#string-and-bytes-literals
it talks of this explicitly

But I still find it strange -- I would have expected this kind of error behavior:

>>> "A string" "another incomplete
SyntaxError: EOL while scanning string literal
>>> 

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web