Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed1a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <3894022.plrvF2nHWu@PointedEars.de>
References: <f7b84d9d-c559-4711-ad63-1deea5f12c62@googlegroups.com> <med6mn$ag9$6@dont-email.me> <3533816.ZYnZ2OzjCs@PointedEars.de> <mailman.51.1426995416.10327.python-list@python.org> <3971951.908YQu3oQO@PointedEars.de> <mailman.52.1426997516.10327.python-list@python.org> <1504323.jUKfeKbQsP@PointedEars.de> <mailman.181.1427346636.10327.python-list@python.org> <2362875.FIK8ImHTJA@PointedEars.de> <mailman.211.1427394586.10327.python-list@python.org> <1823599.Pr2V0MPR6q@PointedEars.de> <mailman.223.1427412471.10327.python-list@python.org> <9781856.5cutuNVPEq@PointedEars.de> <mailman.300.1427615834.10327.python-list@python.org> <3894022.plrvF2nHWu@PointedEars.de>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Tue, 31 Mar 2015 01:23:53 -0600
Subject: Re: A simple single line, triple-quoted comment is giving syntax error. Why?
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.362.1427786682.10327.python-list@python.org>
Lines: 174
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:88368

On Sun, Mar 29, 2015 at 4:41 AM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Ian Kelly wrote:
>
>> [=E2=80=A6] Thomas 'PointedEars' Lahn [=E2=80=A6] wrote:
>>> Ian Kelly wrote:
>> Why should the burden of proof be on me in the first place?
>
> Because *you* made the claim that =E2=80=9CSTRING+=E2=80=9D 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 productio=
n
>     rules of a formal grammar such that
>
>       C =E2=87=92 D =E2=87=92 x
>
>     is a production chain if there are production rules
>
>       C =E2=86=92 D
>       D =E2=86=92 x.
>
>     [Note the difference between =E2=80=9C=E2=87=92=E2=80=9D and =E2=80=
=9C=E2=86=92=E2=80=9D.]

Sure.

> (2) Let the statement =E2=80=9Cx is an A=E2=80=9D be true if x can be pro=
duced in a
>     production chain starting with or including the non-terminal A
>     left-hand side =E2=80=93
>
>       x =E2=88=88 A =E2=86=94 =E2=88=83A (=E2=80=A6 =E2=87=92 A =E2=87=92=
 =E2=80=A6 =E2=87=92 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* a=
n A
> and a B.  Because what matters is _not_ the practical result of productio=
n
> 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 presente=
d
> 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 befor=
e,
> or at least ambiguous, so that the possibility arises for one to say =E2=
=80=9CI did
> not mean that=E2=80=9D 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 i=
n
>> "hucr,.@#%c|42ptqc$".
>
> False analogy.  The =E2=80=9C42=E2=80=9D in there cannot be produced by =
=E2=80=9Cexpr=E2=80=9D *in that
> context* (it can only be produced by =E2=80=9CSTRING=E2=80=9D).

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 =E2=9F=A8"foo" "bar"=E2=9F=
=A9 that
contains an expr node for each STRING is an invalid parse, just as a
parse tree of =E2=9F=A8hucr,.@#%c|42ptqc$=E2=9F=A9 that isolates =E2=9F=A84=
2=E2=9F=A9 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 ar=
e
>>> 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 =E2=80=9CSee above=E2=80=9D 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.