Thread: Why should I learn Lisp?

Originally Posted by Alpo

@MutantJohn - Why PHP though? What does it have some advantage over other languages? Like for instance if I knew C++, HTML, JavaScript, and CSS, would there still be a need for PHP?

It's a bit difficult to implement server-side scripting in C++, for the lack of a proper framework. But he did have other more interesting options. When Laserlight first suggested Python, I wholeheartedly agreed. Not only he gets server-side scripting, but he gets to learn a programming language that is ubiquitous across a large range of other applications. Being a general purpose language, he can use it to code GUI and CLI applications, code stored procedures inside databases and extend applications with scripting.

Originally Posted by Alpo

Aren't you a moderator though? Oh lord, laserlight's compromised too, everyone run!

Our accounts are all ran by our little brothers.

Originally Posted by MutantJohn

Python is a great noobie language because the language itself literally forces you to have a consistent indentation style. I'm not a big fan of that. I prefer being anally retentive when I want/like to be.

Consistent indentation is a necessity in any programming language. It's also somewhat hard to avoid. After all, you aren't going to change your tab spaces configuration mid file.

Python is surprisingly permissive in what it lets you do with whitespaces. The expressions below will result in the same working code.

Code:

print(int    ('4') + 4)
print(int('4') + 4)

Consistent indentation is only imposed on the lines after the first. That is, it needs to remain consistent only on lines that are related to the current nested block/ The following two 'if' constructs are valid code:

Code:

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


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

Line continuation characters, like parenthesis, allow complete indentation freedom. The following is valid python code:

Code:

print(
            4
                +
      1
              )

And since you can wrap almost anything in parenthesis, you can create all forms of indentation. The following is also valid python code, and very similar to what you would see on a C code snippet:

Code:

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

Incidentally, it's not only parenthesis that can work as line continuations characters. Curly braces and square brackets do too. But these have attached semantics and depending of how they are applied, can have undesired side-effects.

Code:

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

# The above outputs:
# True
# {None}


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

# The above outputs:
# True
# [None]

And there's also the semicolon, which removes most needs for indentation by grouping discreet compound statements into a single line. The following is working code:

Code:

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

I hope I have shown to you that Python is in fact a whole lot more permissive than say delimiter-based languages. Its one and only indentation rule is actually pretty simple and an universal best practice among all programming languages.

The only thing that may trip some coders is instead the absence of imposed delimiters. But my experience has shown me that it is only a matter of a short time until one just gets used to it and Python code ends up reading as easily, if not more easily, than C or C++.

EDIT:
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. It's just not a paired-delimiter as we usually see in other languages.

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.

O_o

If you actually want to get technical, the `:' token isn't the "open block-delimiter" for the Python language.

Let's take a brief look at part of the grammar for a parser for a language not unlike C for the sake of context:

Code:

add_expr: term ('+' term)*
// ...
opr_expr: add_expr | sub_expr // many more
// ...
spl_stmt: (opr_expr | fcl_expr) ';'
// ...
grp_stmt: '{'  (spl_stmt)* '}'
// ...
bnch_if: "if" '(' cnd_stmt ')' grp_stmt | spl_stmt

The group statement can't exist without the "open block-delimiter" and "close block-delimiter".

Let's take a brief look at part of the grammar for the Python language:

Code:

add_expr: term ('+' term)*
// ...
opr_expr: add_expr | sub_expr // many more
// ...
smll_stmt: opr_expr | prnt_stmt // many more
// ...
grp_stmt: NL INDT smll_stmt+ DINT
// ...
bnch_if: 'if' cnd_stmt ':' grp_stmt | smll_stmt

The branch itself can't exist without the ':' character.

Now let's look at some similar code for both languages:

Code:

if True:
    print("Hello, World!")

Code:

if(true)
{
    printf("Hello, World!");
}

Code:

The ':' character is more related to the ')' than the '{' character.

Soma

Originally Posted by phantomotap

O_o
If you actually want to get technical, the `:' token isn't the "open block-delimiter" for the Python language.

Well alright But your explanation didn't convince me either.

To get technically technical, let's look instead at suite, where blocks are actually defined:

Code:

compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated
if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite]
while_stmt: 'while' test ':' suite ['else' ':' suite]
for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite]
try_stmt: ('try' ':' suite
           ((except_clause ':' suite)+
            ['else' ':' suite]
            ['finally' ':' suite] |
           'finally' ':' suite))
with_stmt: 'with' with_item (',' with_item)*  ':' suite
with_item: test ['as' expr]
except_clause: 'except' [test [('as' | ',') test]]
suite: simple_stmt | NEWLINE INDENT stmt+ DEDENT

Along with funcdef and classdef, all suite is preceded by the : delimiter. So : is really more like '{'. And not '('

[Edit]
TL;DR: You may consider what constitutes the block statement associated with branching, class definitions, and similar by considering what characters semantically and grammatically bind to what tokens. The `simple_stmt' and `stmt' do not have a rule for a leading ':' character so any sentence beginning with a ':' is invalid. The actual block statement, the alternative to a single `simple_stmt' within the `suite' rule, begins with the `NEWLINE' and `INDENT' rule leaving the ':' character to bind with the other related statements.
[/Edit]

To get technically technical, let's look instead at suite, where blocks are actually defined:

O_o

You've confused yourself by looking at the official grammar because they didn't separate, as I did on your behalf, the statement rule versus block rule.

I'll show you again by making the same split with the copy of the official grammar you posted.

Code:

compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated
if_stmt: 'if' test ':' suite ('elif' test ':' suite)* ['else' ':' suite]
while_stmt: 'while' test ':' suite ['else' ':' suite]
for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite]
try_stmt: ('try' ':' suite
           ((except_clause ':' suite)+
            ['else' ':' suite]
            ['finally' ':' suite] |
           'finally' ':' suite))
with_stmt: 'with' with_item (',' with_item)*  ':' suite
with_item: test ['as' expr]
except_clause: 'except' [test [('as' | ',') test]]
BLOCK: NEWLINE INDENT stmt+ DEDENT
suite: simple_stmt | BLOCK

The `suite' rule doesn't just represent a block. The `suite' rule represents a statement or a block.

The "or" is the source or your confusion.

Remove the "or" to yeild "suite: BLOCK" and consider the following:

Code:

# The example is invalid.
if True: print("Hello, World!")
# if(true) printf("Hello, World!");

Code:

# The example is valid.
if True:
    print("Hello, World!")
# if(true){printf("Hello, World!");}

Remove the "or" to yeild "suite: simple_stmt" and consider the following:

Code:

# The example is valid.
if True: print("Hello, World!")
# if(true) printf("Hello, World!");

Code:

# The example is invalid.
if True:
    print("Hello, World!")
# if(true){printf("Hello, World!");}

Once again, the ':' character binds as part of the relevant statement not the block.

If the ':' character did bind as you suggest to the block, you could change the grammar:

Code:

compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated
if_stmt: 'if' test suite ('elif' test suite)* ['else' suite]
while_stmt: 'while' test suite ['else' suite]
for_stmt: 'for' exprlist 'in' testlist suite ['else' suite]
try_stmt: ('try' suite
           ((except_clause suite)+
            ['else' suite]
            ['finally' suite] |
           'finally' suite))
with_stmt: 'with' with_item (',' with_item)*  suite
with_item: test ['as' expr]
except_clause: 'except' [test [('as' | ',') test]]
suite: simple_stmt | ':' NEWLINE INDENT stmt+ DEDENT

Actually, let's go ahead and do the same split for convenience:

Code:

compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated
if_stmt: 'if' test suite ('elif' test suite)* ['else' suite]
while_stmt: 'while' test suite ['else' suite]
for_stmt: 'for' exprlist 'in' testlist suite ['else' suite]
try_stmt: ('try' suite
           ((except_clause suite)+
            ['else' suite]
            ['finally' suite] |
           'finally' suite))
with_stmt: 'with' with_item (',' with_item)*  suite
with_item: test ['as' expr]
except_clause: 'except' [test [('as' | ',') test]]
BLOCK: ':' NEWLINE INDENT stmt+ DEDENT
suite: simple_stmt | BLOCK

Remove the "or" from the augmented grammar to yeild "suite: BLOCK" and consider the following:

Code:

# The example is invalid.
if True print("Hello, World!")
# if(true) printf("Hello, World!");

Code:

# The example is valid.
if True:
    print("Hello, World!")
# if(true){printf("Hello, World!");}

Remove the "or" from the augmented grammar to yeild "suite: simple_stmt" and consider the following:

Code:

# The example is valid.
if True print("Hello, World!")
# if(true) printf("Hello, World!");

Code:

# The example is invalid.
if True:
    print("Hello, World!")
# if(true){printf("Hello, World!");}

You may not be able to see it with the examples I've shown, but we have introduced a semantic ambiguity.

Let's consider a non-literal condition with the augmented grammar to illustrate an instance of the ambiguity:

Code:

if var1 - DoSomething() + var2 and print("Hello, World!")

These example are both valid code from among the possible interpretations:

Code:

if var1: -DoSomething() + var2 and print("Hello, World!")

Code:

if var1 - DoSomething(): +var2 and print("Hello, World!")

Along with funcdef and classdef, all suite is preceded by the : delimiter.

Try looking at the examples in terms of finding what is missing:

Code:

if var == 5
    print("Hello, World!")

Code:

if (var == 5
{
    print("Hello, World!")
}

In both cases, the block--the `suite' rule--itself is a valid sentence.

Soma

[Message]*blah* *blah* *grammar* *blah* *redefine* *blah* *blah* *blah*[/Message]

O_o

Really? Really?

Yeah. Fine. You can rebuild the parser to change the grammatical binding of a character to a token.

Let's do that now!

Code:

add_expr: term ('+' term)*
// ...
opr_expr: add_expr | sub_expr // many more
// ...
spl_stmt: (opr_expr | fcl_expr) ';'
// ...
grp_stmt: '{'  (spl_stmt)* '}'
// ...
cmpltyfngstupid_spl_stmt: ')' (opr_expr | fcl_expr) ';'
// ...
cmpltyfngstupid_grp_stmt: ')' '{'  (spl_stmt)* '}'
// ...
bnch_if: "if" '(' cnd_stmt cmpltyfngstupid_grp_stmt | cmpltyfngstupid_spl_stmt

Code:

if(true) printf("Hello, World!"); // good

Code:

if(true)
{
    printf("Hello, World!"); // still good
}

Congratulations. The ')' character grammatical binds to the block.

Let's style the code for semantics to match the grammar.

Code:

if(true
){
    printf("Hello, World!"); // still good
}

That's really ....... dumb and ridiculously ugly; go die in a fire.

Soma