Python syntax in Lisp and Scheme

Alexander Schmolck a.schmolck at gmx.net
Tue Oct 7 16:25:53 EDT 2003


Joe Marshall <jrm at ccs.neu.edu> writes:


> Alexander Schmolck <a.schmolck at gmx.net> writes:
> 
> > prunesquallor at comcast.net writes:
> (I'm ignoring the followup-to because I don't read comp.lang.python)

Well, I supposed this thread has spiralled out of control already anyway:)
 
> Indentation-based grouping introduces a context-sensitive element into
> the grammar at a very fundamental level.  Although conceptually a
> block is indented relative to the containing block, the reality of the
> situation is that the lines in the file are indented relative to the
> left margin.  So every line in a block doesn't encode just its depth
> relative to the immediately surrounding context, but its absolute
> depth relative to the global context.  

I really don't understand why this is a problem, since its trivial to
transform python's 'globally context' dependent indentation block structure
markup into into C/Pascal-style delimiter pair block structure markup.

Significantly, AFAICT you can easily do this unambiguously and *locally*, for
example your editor can trivially perform this operation on cutting a piece of
python code and its inverse on pasting (so that you only cut-and-paste the
'local' indentation). Prima facie I don't see how you loose any fine control.

> Additionally, each line encodes this information independently of the other
> lines that logically belong with it, and we all know that when some data is
> encoded in one place may be wrong, but it is never inconsistent.

Sorry, I don't understand this sentence, but maybe you mean that the potential
inconsitency between human and machine interpretation is a *feature* for Lisp,
C, Pascal etc!? If so I'm really puzzled.

> There is yet one more problem. The various levels of indentation encode
> different things: the first level might indicate that it is part of a
> function definition, the second that it is part of a FOR loop, etc. So on
> any line, the leading whitespace may indicate all sorts of context-relevant
> information. 

I don't understand why this is any different to e.g. ')))))' in Lisp. The
closing ')' for DEFUN just looks the same as that for IF.

> Yet the visual representation is not only identical between all of these, it
> cannot even be displayed.

I don't understand what you mean. Could you maybe give a concrete example of
the information that can't be displayed? AFAICT you can have 'sexp'-movement,
markup and highlighting commands all the same with whitespace delimited block
structure.

> 
> Is this worse than C, Pascal, etc.?  I don't know.

I'm pretty near certain it is better: In Pascal, C etc. by and large block
structure delimitation is regulated in such a way that what has positive
information content for the human reader/programmer (indentation) has zero to
negative information content for the compiler and vice versa. This is a
remarkably bad design (and apart from cognitive overhead obviously also causes
errors).

Python removes this significant problem, at as far as I'm aware no real cost
and plenty of additional gain (less visual clutter, no waste of delimiter
characters ('{','}') or introduction of keywords that will be sorely missed as
user-definable names ('begin', 'end')).

In Lisp the situtation isn't quite as bad, because although most of the parens
are of course mere noise to a human reader, not all of them are and because of
lisp's simple but malleable syntactic structure a straighforward replacement
of parens with indendation would obviously result in unreadable code
(fragmented over countless lines and mostly in past the 80th column :).

So unlike C and Pascal where a fix would be relatively easy, you would need
some more complicated scheme in the case of Lisp and I'm not at all sure it
would be worth the hassle (especiallly given that efforts in other areas would
likely yield much higher gains).

Still, I'm sure you're familiar with the following quote (with which I most
heartily agree):

 "[P]rograms must be written for people to read, and only incidentally for
   machines to execute."

People can't "read" '))))))))'.

> Worse than Lisp, Forth, or Smalltalk?  Yes.

Possibly, but certainly not due to the use of significant whitespace. 


'as






More information about the Python-list mailing list