1. Existing code should continue to work without modification. Runtime flags
deciding between two separate coding styles aren't very appealing, though
optionally increased checking wouldn't harm anyone if it's only depending
on a local context - at most a file at a time, but a per-code-block style
would be preferrable, allowing cut-and-paste between different files on a
per-block basis.
2. Indentation should not fool the human reader about limits of code blocks.
However, if the programmer wants improved safety, the reinterpretation of
editing mistakes resulting in wrongly indented code should be unlikely. A
pretty-printer alone wouldn't be sufficient, since it would force this on
everyone (and old code), which appears unlikely to find consensus.
3. For automatically generated code, including usage of a preprocessor which
doesn't respect indentation rules, it should be possible to reindent such
generated code automatically. In that case, the application of some other
tool than the Python parser would be acceptable.
4. For the benefit of poor editors as part of a Python application, the tool
mentioned above should be available as a Python function mapping a string
of arbitrarily indented code to something acceptable by the parser. Since
this kind of editing seems unlikely to be used for the development of big
programs, the restriction to a safer coding style - checked by the tool -
should be acceptable. (In the case of an integrated development system, a
more sophisticated editor would be a reasonable requirement.)
Language modification:
Where the language now accepts a colon and an indented code block, the colon
may be replaced by the keyword "do" and the block be closed with "end" "???"
on the level of the block statement (i.e. not the indented code) where "???"
is the keyword of the block statement ("if", "while", "try" etc.). Using the
keyword "do" also requires the closing statement, whereas using a colon does
not allow the end bracket. Different statements need not use the same style.
Incompatibility:
The addition of the new keywords "do" and "end" may invalidate some old code
using them as normal identifiers. If the discussion reveals the existence of
large amounts of such code, and the change of those identifiers would appear
too problematic (even when supported by some tool), it should be possible to
find another syntax. Otherwise, I'd prefer using keywords over using special
characters.
Tools:
The exact nature of support tools may better be deferred, until the language
modification is agreed upon. Anything from a simple string transformer up to
a standardized parsing module with a clearly defined interface to the syntax
tree might come out - depending on the effort of the tool builders.
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>