Re: New Syntax -- with an implementation

George Reynolds (george@vicorp.com)
Thu, 2 Jun 94 14:12:03 EDT

>>
>> There have been a variety of very good posts (and some private
>> emails) giving reasons both for and against the delimeter syntax
>> change. The most prominent is advanced editor functionality.
>> Good. This is the kind of discussion we need.
>>
>> In case the main point of my post about the proposed change
>> was lost in the translation, it's just this:
>>
>> I want you to tell me the WHY, not the WHAT.
>>
>>

All the reasons have already been given. I provide a summary from a few
postings below. I support Don's change. Its backward compatable, its
elegant, it makes Python easier to use and I suspect will widen Python's usage
( I recall a posting from someone using Tcl that the reason they are
not using Python is the white space based syntax. Dons proposal is not
white space based, it allows formatting to be enforced in a way thats consistent
with the language)

I suspect that all the arguments are in. Lets let Guido decide.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Here is a summary of the reasons given for the inclusion of an
optionaly-required 'end' statement.

[George Reynolds]
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.

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]
The goal is to
provide optionally-required-end-statements. That is, it makes it
possible (optional) to write compound statements that are terminated
by a required end statement. This is not to be confused with
optionally allowing an end statement. An optional end statement is of
no more value than a comment that says '# end'. When writing the
initial part of a compound statement (if, while, etc), the programmer
must decide then if the statement will be terminated by an end
statement. This makes it possible for the parser to check that it was
in fact terminated with an end statement.

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

It is quite a bit easier to fix up the indentation of a C program than
it is to fix up the indentation of a Python. Given a good set of
"style-rules" and a messed up C program, there is only one way to fix
up the indentation. Given Python's current syntax and a messed up
Python program, there are many ways to fix it up... and each means
somthing different. To properly re-indent a Python program you must
read the code and figure out which of the many possible combinations
is the right one.

Python already has a 'begin' statement... it is written as a colon.
The 'begin' is interpreted relative to its position within the code,
that is, move the code, the 'begin' moves with it. But the current
version of the 'end', the DEDENT token, is an absolute value, and is
not relative to its context, move the code and the DEDENT does not
know that it was moved. This adds an element of asymmety to the
language that I feel should be removed.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ 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 +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++