Re: [RFC] Draft Proposal for New Python Syntax

George Reynolds (george@vicorp.com)
Thu, 26 May 94 14:59:54 EDT

There are two threads of discussion being carried out under the
general heading of "Automated Indentation".

1. Enforcing Python's use of white space to represent the
intentions of the programmer

2. Eliminating white space as a meaningful token.

Thomas Kofler's proposal has to do with thread 2.
This comment has to do with thread 1 and is a follow up to
Don Beaudry's note a while back making essentially the proposal
suggested below.

When the original "Automated indentation" thread began many people
said in effect: 'What problem are you trying to solve'?
GOOD POINT.
Ok. Here's the problem:

Python tries to capture the following idea:
White space should be consistent with the semantic intent of the
programmer.

Unfortunatly, in the current implementation of Python, white space
IS the representation of the semantic intent of the programmer.
This makes it impossible for the parser to check for consistency
since there is nothing to check against.

What I want is a language construct which captures the semantic
intent of the programmer, AND THAT WHITE SPACE SHOULD BE CONSISTENT
WITH THIS INTENT.

In addition the white space representation of semantics is only
locally valid. This leads to the problem that automated indentation
is impossible and that cutting and pasting a code fragment requires
by hand re-indentation.

So the question now is: How to capture the semantic intent of the
programmer? I believe this could be done in a very simple way.

Here's an example

Current Python:
--------------
def rotateAll( param, param ):
lineList = ...
blah
blah
for item in lineList:
blah
blah
blah
blah

Proposed Python:
---------------
def rotateAll( param, param )
lineList = ...
blah
blah
for item in lineList
blah
blah
end
blah
blah
end

Guido's proposal in this regard (optional end) is
no better than a comment (i.e. '# end'). There is no way for the
parser to enforce consistency in that scheme. In this proposal,
the ':' is optional (so its backward compatible) and the lack
of a ':' allows the parser to check for the 'end' and generate an
error if its not there.

Note:
-----

The following would be a syntax error:

if x > 1
foo
bar
end

To summarize:
1. Indentation is still required.
2. The lack of a ':' is the trigger to the parser that an
'end' will be required, and moreover the parser can check
the consistency of the indentation with start and
ending of blocks.
3. Beginning and ending of blocks must be consistent with indentation.
4. An automated indenter could produce the 'correct' indentation
independent of its context (i.e. the indentation implied by the 'end'
statements. With a simple glance one could determine if the
'ends' were in the 'right' place. (Of course it still could not do
anything with ':' defined blocks)
5. Don't like it?... don't use it.

Don Beaudry has verified that a non-ambiguous grammar exists which
implements this optional syntax.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ George Reynolds +
+ VI Corporation +
+ 47 Pleasant St +
+ Northampton MA 01060 +
+ I heard a pay phone ringing, +
+ george@vicorp.com It just about blew my mind. +
+ 413-586-4144 I picked it up and said hello +
+ And this foot came through the line. +
+ Bob Dylan +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++