Thread: Why should I learn Lisp?

Nominal Animal has spoken the secret thought that crossed my mind when I first saw this topic.

Why should I learn to Lisp?

O_o

Lusty lady lycans love a leaky lisp.

Soma

Originally Posted by Nominal Animal

I think this is the best possible point to mention that every time I look at the thread list, I read the title of this thread as

Why should I learn to Lisp?

There's rarely a good reason to stick to the plan.

(But it would be ok if laserlight forked the discussion, I guess)

@Phantomotap,

Have to digest your post later. But in the meantime, the suite statement represents a nested block or statement, which is a category concept above the notion of a simple statement, or a group of statements (the latter of which Python has no concept of, beyond +). A nested block is what we are discussing here. A simple statement has no bearing in the discussion since it can appear anywhere in the code and doesn't carry the semantics necessary for the discussion of "What constitutes the delimiter for nested code? And suite makes it clear that nested code is either a simple statement or a block of simple statements. In Python as in many other languages.

The grammar does not make the separation for good reason. And if you look at your own grammar code, neither have you. When you went to be more explicit about that separation and broke the 'or', you introduced ambiguity, which could only be resolved by introducing a new branch (which we could anyways, I'll give you that).

I would marginally agree with you, if you wanted to discuss nested code in the strict context of a code block made up of more than one statement. Then I would say IDENT and EDENT are the good looking fellas that appear to delimit blocks of statements. Sure. But that says nothing about nested code, which is defined one branch up in the parser.

Meanwhile, the following is perfectly valid python code:

Code:

if (True):
    print(True)
else:
    print(False)

The parser travels through suite and into simple_stmt branch to parse the print() statement. It's important to note the order. But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.

But as I said, I have to look at your post more carefully later. In a rush for work.

But as I said, I have to look at your post more carefully later.

o_O

Your sloppy use of extraneous grouping, discussed below, to show anything about the ':' character is foolish and a waste of that time available.

I spent about fifteen minutes responding, but I'll gladly stop posting before responding to another such bit of nonsense.

The grammar does not make the separation for good reason.

The reason being that the ':' doesn't bind with the block in either event.

When you went to be more explicit about that separation and broke the 'or', you introduced ambiguity,

Code:

A1: simple_stmt
A2: A1
A3: NEWLINE
A4: A3 INDENT
A5: A4 stmt+
A6: A5 DEDENT
A7: A6
suite: A2 | A7

The grammar hasn't been augmented. I've not introduced any sort of ambiguity.

Your an idiot if you think separation introduces the ambiguity.

which could only be resolved by introducing a new branch.

When you choose to bind the ':' as being part of the block, you introduce ambiguity.

An ambiguity, by the way, that isn't resolved by intruding a new branch.

But that says nothing about nested code, which is defined one branch up in the parser.

Correct. Nested code, a compound statement, has nothing to do with a block statement which is a block of statements.

We've been talking about block statements ("Technically it is not true that Python doesn't impose a block delimiter. That delimiter exists and it is obligatory. It's the colon you see in the code snippets above.") the entire time so I'm not sure why you've brought up compound--"nested code"--statements.

In any event, you are definitely still wrong if you think the ':' character is the "open compound-statement" delimiter.

Code:

while(a): if(b): a = c() else: a = d()

You aren't seeing three compound statements--"nested code"--delimited by a ':' character.

You are seeing one--"nested code"--compound statement. You see a while-branch statement and a if-branch statement with the option "else" clause.

You do indeed see two simple statements, but the ':' character isn't either a "open simple-statement" delimiter.

Your use of the "nested code" rule doesn't say anything, more below, about the ':' character.

Meanwhile, the following is perfectly valid python code:

The following C++ code is perfectly valid:

Code:

if(((((((((((((((((((((((((((((((true)))))))))))))))))))))))))))))));

The code can be simplified by removing the extraneous grouping tokens:

Code:

if(true);

I can't remove either the '(' or the ')' character. The remaining '(' and ')' characters are part of the `if' itself.

But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.

A language allowing almost arbitrary extraneous grouping tokens doesn't change the delimiter requirements or binding for any characters required as part of a rule.

The following is a valid Python program:

Code:

(((((((((((((((((((((((((((((((True)))))))))))))))))))))))))))))))

The code in the example is also valid as a condition statement.

Code:

if(((((((((((((((((((((((((((((((True))))))))))))))))))))))))))))))): pass

The code can be simplified by removing the extraneous grouping tokens:

Code:

if True: pass

I can't remove ':' character. The ':' character is part of the `if' itself.

The parser travels through suite and into simple_stmt branch to parse the print() statement. It's important to note the order.

Okay...

The parser uses the if_stmt rule to parse the "if" fragment before moving onto the test rule which allows for extraneous grouping tokens through combining other rules which themselves allow for extraneous grouping tokens before moving onto the ':' fragment which neither delimits the test rule or suite rule being part of the "if" rule before moving onto the suite rule which here begins with the alternative NEWLINE INDENT stmt+ DEDENT component before moving onto the "else" fragment before moving onto the ':' fragment which still doesn't delimit the suite statement being part of the "else" component of the "if" rule before moving onto the suite rule which here begins with the alternative NEWLINE INDENT stmt+ DEDENT fragment.

It is very important to note the order.

But you also have wrapped the condition in parenthesis, killing the idea that ':' behaves more like an open parenthesis.

Congratulations. You wrapped the condition in parenthesis.

You very effectively showed that the option grouping tokens you added are extraneous.

You've killed the idea that wrapping a condition in extraneous parentheses changes the meaning of a sentence.

The following is also valid Python code:

Code:

if True:
    (print(True))
else:
    (print(False))

The example shows that the option grouping tokens I added are extraneous.

The example says literally nothing about the ':' character.

*shrug*

I also never said "the idea that ':' behaves more like an open parenthesis", but I'm pretty sure that a mistype.

Soma

Originally Posted by phantomotap

Correct. Nested code, a compound statement, has nothing to do with a block statement which is a block of statements.

We've been talking about block statements ("Technically it is not true that Python doesn't impose a block delimiter. That delimiter exists and it is obligatory. It's the colon you see in the code snippets above.") the entire time so I'm not sure why you've brought up compound--"nested code"--statements.

Damn. You are thick when you want to be. Call me an idiot and behave like an idiot. Typical of you.

That quote is taken from the context of nested statements. I called it a block statement. You are right, it's the wrong term. Smartass.

Originally Posted by phantomotap

In any event, you are definitely still wrong if you think the ':' character is the "open compound-statement" delimiter.

Code:

while(a): if(b): a = c() else: a = d()

You aren't seeing three compound statements--"nested code"--delimited by a ':' character.

You are seeing one--"nested code"--compound statement. You see a while-branch statement and a if-branch statement with the option "else" clause.

I see 2 compound statements and 3 suits there. A while compound statement and an if compound statement wrapped in the while statement suite. The if statement meanwhile -- because of the optional else -- has two suits. Each of the three suites are preceded by a colon.

Originally Posted by phantomotap

You do indeed see two simple statements, but the ':' character isn't either a "open simple-statement" delimiter.

So. What exactly is the ':' character then, if not a delimiter for a suite (suite, which defines nested code)?
What is its purpose then? You must have an opinion, no? Tell us.

Or is this really all because you aren't seeing the colon in the suite definition? Because as much as you write 20 minute long posts, you aren't doing a good job at spinning this, doctor Phantomotap.