Re: New Syntax -- with an implementation

Michael McLay (mclay@eeel.nist.gov)
Thu, 2 Jun 94 09:32:27 EDT

Thomas Kofler writes:
t> there is no satisfactory solution to all
t> the problems related to newlines and indentation

What problems? Please answer this question before proposing a
departure from the current syntax. The LANGUAGE has no problems with
newlines and indentation. Some people may have problems when they use
their old programming habits to write code in Python, but the LANGUAGE
is not at fault here. The LANGUAGE is not ambiguous. Flaws do not
exist in the syntax that cause sequences of Python statements being
interpreted incorrectly. It appears that you just don't like the
syntax.

Donald Beaudry writes:

d> The most compelling reason that I have heard is that, as-is, you
d> cannot reconstruct a properly indented program from an improperly
d> indented one. I agree that Python's indentation-based syntax model is
d> not only elegent, but is also very useful. That is why I did not
d> propose to eliminate. I would like to simply agument it in such a way
d> as to eliminiate its only major flaw.

Is this really a flaw with Python or just sloppy editing? Similar
cut and paste problems can occur in C and they can go completely
undetected. Let's look at an example of a cut and paste activity.
Start with the following equivalent C and Python code sequences.

main(){
int a = 1;
int b, c, g;
if (a) {
b = a;
if (c)
{
c = b;
g = b;
}
}
}

in Python this might be:

a = 1
c = 1
if a:
b = a
if c:
c = b
g = b

Now copy the code from the if(c) statement to a new program sequence:

main(){
int a = 1;
int b, c,d, g;
if (d)
/* reuse the code here */
{
c = b;
g = b;
}
}
Using cut and paste in Python this would be:

d = 1
b = 1
if d:
c = b
g = b

Using the emacs editor the indentation can be cleaned up with the C-c
TAB py-indent-region command. This will force the copied lines to
move to the proper indentation level. In this example the code would
have executed properly without reindenting, but there are cases where
it would have problems.

Using cut and paste in C is not without danger. Had the braces not been
included when making the copy the sequence would still have been a legal
program, but it would not have been the intended algorithm.

main(){
int a = 1;
int b, c,d, g;
if (d)
/* reuse the code here */
c = b;
g = b;
}

This is a bit of a contrived example, but since you didn't provide an
example I had to make up my own. If I've missed the point, please
clarify your position with a real example of a cut and paste situation
where using C-c TAB would not fix the code. I realize that not
everyone uses emacs, but that's not the issue here. Simple tools can
be created, such as pindent, that will assist people in using the
Python syntax.

Please don't propose "fixing" the problem by changing the syntax when
the problem is the use of the wrong tools and techniques when writing
code. This debate appears to be about treating the symptoms of a
problem rather than finding the root cause and fixing that instead.

t> I think that there is no satisfactory solution to all
t> the problems related to newlines and indentation as long backward
t> compatibility must be provided. That is why I proposed to depart
t> from the current syntax.

If the syntax is different and it is not backwards compatible with
Python, then it is a different language. Forming a new sect is your
prerogative if you feel the Python language has a flawed syntax. Pick
a name for your new language and start writing code. I'll continue to
follow Guido's language until your new language proves to be better.

Michael