Revision C-94-05-24
May 24 1994
Thomas Kofler
kofler@ubilab.ubs.ch
0) Introduction
When I learned about Python[1], I found that it is an interesting and
powerful language -a language I would like to use for serious work. I
found, however, that the current syntax has a serious drawback: White
space has sometimes a syntactic meaning. I acknowledge the minor
advantages of the current syntax, but they do not outweigh the
disadvantages if programming even in the small-to-medium scale.
Since I am firmly convinced that the current syntax is a serious
problem -I am not a language lawyer- I worked out this draft
proposal. I would be very pleased if this work could support the
spread of Python. The paper contains the following sections:
- Requirements and Benefits
- The New Syntax
- Compatibility with Current Syntax
- How To Continue
- Acknowledgements
- Appendix: References and Materials
1) Requirements and Benefits
1.1) Requirement: Elimination of Syntactic White Space
The new syntax should eliminate all syntactic meaning from white
space. As a constraint, the resulting syntax should look close to
the current syntax, and require minimal changes of the current syntax
and minimal efforts for an implementation based on the reference
implementation by Guido van Rossum.
1.2) Expected Benefit
The new syntax makes programs immune against semantical changes due
to different formating.
The new syntax eliminates the formating policy as imposed by the
current language. There is no "true" formating style, and a language
should not impose any policy on its users, but should provide
mechanism according to its design goals only.
In particular, the new syntax is expected to and will:
1) ease the editing of Python code in practice
2) ease the use of macro processors and code generators
3) relieve a burden from developers embedding Python into
interactive applications that allow users to enter Python source
2) The New Syntax
2.1) Productions
1) The following productions replace the productions of the same
name in [1]:
stmt: simple_stmt | block.
simple_stmt: small_stmt ';' | compound_stmt.
suite: ':' simple_stmt | block.
2) A new production is introduced:
block: '{' stmt+ '}'.
3) Every occurence of
alpha ':' suite beta
is replaced by
alpha suite beta.
4) In the production for atom, the clause:
'{' [dictmaker] '}'
is changed to:
'{|' [dictmaker] '|}'.
5) The following productions replace the productions of
the same name:
single_input: [stmt].
file_input: stmt*.
eval_input: testlist.
2.2) Examples of Legal and Illegal New Syntax
#------ Legal New Syntax -------------------
def f(): pass;
class C: pass;
#
if a: ta(); else: fa();
if a { ta(); } else { fa(); }
if a:
if b: tb();
else: fb();
# dangling else resolved as usual: it belongs to the most
# recent 'if', 'for', or 'while', etc.
#
if a {
if b: tb(); else: fb();
}
# resolves the dangling else and is easier to read
#
def f() { pass; }
def g() {
{ a= 1; b= 2; }
return k(a,b); # a and b visible!
}
# We can write a block any place where a statement is expected:
# A block allows for grouping, but does not open a new
# nested scope!
#
if a: ta();
else: {
fa();
}
#
dict= {||}; dict= {| a:b, c:d |};
# dictionary literals (display in Python speak)
#------ Illegal New Syntax -------------------
if a: ta() else: fa();
# ^^^ missing semicolon
if a: f();;
# ^^^ semicolon unexpected
# This could be legal if we have an empty statement.
#
while condition {
condition= f();
};
#^^^ semicolon unexpected
#
def f() { }
# ^^^ statement expected
# This could be legal if we have an empty statement.
#------ Current vs. New Syntax
#
if a:
aa()
bb()
# ^^^ syntax error: semicolon expected
# Legal current syntax, but illegal in new syntax
if a:
aa();
bb();
# Legal new syntax but different semantics. Meaning in current syntax:
if a:
aa();
bb();
2.2) Interactive Use
There is no great difference between current and new syntax
for interactive use. Statements have to be terminated, of course,
by either semicolon or a closing brace, depending on what has been
entered before. The user can take advantage, however, of the new
syntax. For example:
>>> if c: tc(); else: fc();<NEWLINE>
>>> # not possible with current syntax!
If it is possible to specify an else part or more exception clauses,
the user enters an empty line as before to indicate that nothing more
will follow.
In contrast to the current syntax, this behaviour is accomplished in
the scanner. In the case of an empty line, the scanner produces the
token sequence 'pass' ';' if there could be more input.
>>> if c: tc;<NEWLINE>
... pass;<NEWLINE>
>>> while (c) { tc(); c= cc(); }
... <NEWLINE>
>>> # equivalent to enter pass;
2.3) Discussion
White space does not have a syntactic meaning anymore.
The resulting syntax for grouping statements comes very close to
C or C++. Empty statements, however, are not allowed although this
would be possible. Empty statements are sometimes convenient, but
easily leads to code that does not mean what the programmer means.
The introduction of blocks allows for nesting local scopes of the
language.
Dictionary literals are rare. Thus, the new syntax for denoting
dictionary literals is not a loss.
I rejected keywords like 'end', 'end if', etc. for the use as block
closers. First, introducing new keywords is always problematic, and
many people would not accept that. Second, keywords need more key
strokes. Third, keywords are less visible than combinations of
non-alphanumeric characters.
3) Compatibility with Current Syntax
There is no general compatibility between the current and the new syntax.
Binary code produced from either current or new syntax might be compatible,
but this is not a requirement. Implementors are encouraged, however,
to provide compatibility on the binary level. Note that the new syntax
does not involve any conceptual change.
A converter can be provided that transforms source code written in current
syntax to code in new syntax. This will be important for a smooth and
quick transition from current to new syntax.
4) How To Continue
Requests to change or to add something this draft proposal are welcome
accepted as long they do not affect the primary aim of eliminating the
syntactic meaning of white space. The draft proposal will be followed
by a proposal by the author taking the feedback into account.
5) Acknowledgements
Thanks to Guido van Rossum for inventing and conducting the Python
reference implementation, and many other people contributing to
Python.
A) References and Materials
[1] Guido van Rossum: Python Language Reference Manual - Release 1.0.0.
Stichting University, Amsterdam, Januar 26 1994.
Available by Anonymous FTP: ftp://ftp.cwi.nl/pub/python/XXX
This draft proposal has been posted to the news group comp.lang.python
in May 1994, and is available from the author, or by Anonymous FTP:
ftp://ftp.ubilab.ubs.ch/pub/python/python-syntax-proposal-dc.txt
The author can be reached at the following postal address:
Thomas Kofler
Ubilab
Union Bank of Switzerland
Bahnhofstr. 45
CH-8021 Zurich, Switzerland
Fax: +41-1-236 4671