Python's Lisp heritage

[Jacek Generowicz]

"James J. Besemer" <jb at cascade-sys.com> writes:

> Paul Foley wrote:

[snip]

> > In any case, parentheses are not used around sub-expressions, or to
> > separate or group statements.  They're only used (in evaluated
> > contexts) for "function" calls, and most other languages, including
> > Python, use parentheses for that purpose, too:
> >
> >  Python: foo(x)
> >  Lisp: (foo x)
> >
> > Same number of parentheses, right?
> 
> Besides, this is an entirely contrived, intellectually dishonest example.

I disagree. It accurately illustrates the point being made. It is
important that the point be made, because all too many people believe
the lies they are told about parentheses in lisp.

> First off, parens ARE used around sub expressions last I checked,

No, as Paul said, they are used for "function calls". Admittedly, in
mathematical expressions function call often coincide with
sub-expressions, but it does depend on the sub-expression in
question. Compare

   (+ 1 2 3 4 5 6 7 8 9 10)

with

   1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10

Gosh, what a lot of typing I have to do in Python, compared to lisp.

> And, oh yeah, I forgot, aside from the parentheses, the pervasive
> prefix notation can be a drag.  And I'm the type that still finds
> HP's stack notation less confusing in a calculator than infix.  But
> having to mentally convert everything back and forth between infix
> and prefix notation also can make you nuts.

> That being said, I acknowledge that arithmetic is a small part of
> some large systems and once you rise above the lower levels of
> abstraction, "everything" is function (or member) calls, and your
> original example begins to be more valid.  Still, arithmetic crops
> up and awful lot even then and can confound even the most
> enthusiastic programmer.

I don't think you will find many people who will argue that prefix
notation is easier to type or read than infix, when dealing with
mathematical formlae, particularly as those mathematical formulae are
likely to be copied from or compared to ones written on paper, with
all the usual operator precedences taken for granted. But, if you are
dealing with mathematical expressions, then, obviously, you will use
some sort of infix notation macro:

  [2]> (load "utilities/infix.lisp")
  ;; Loading file utilities/infix.lisp ...
  ;;; ******************************************************************
  ;;;   Infix notation for Common Lisp.
  ;;;   Version 1.3  28-JUN-96.
  ;;;   Written by Mark Kantrowitz, CMU School of Computer Science.
  ;;;   Copyright (c) 1993-95. All rights reserved.
  ;;;   May be freely redistributed, provided this notice is left intact.
  ;;;   This software is made available AS IS, without any warranty.
  ;;; *******************************************************************
  ;; Loading of file utilities/infix.lisp is finished.
  T
  [3]> #i(1+2*3)
  7
  [4]> #i(2*asin(1))
  3.1415927
  [5]> #i(1+2*3/4-5)
  -5/2

Incidentally, it would be interesting to see how many people would
correctly work out in their heads (on first attempt) what 1+2*3/4-5
evaluates to (leaving aside the fact that in Python it evaluates to
-3[*]) . . . and then compare it to the success rate when considering
the equivalent (+ 1 (/ (* 2 3) 4) -5). Or maybe how long it takes them
to get the right answer in each case.

> > I'd expect Lisp syntax to be
> > rather less error-prone, if anything, since it's much simpler
> 
> I think that's debatable.  Certainly simplicity makes it easier to
> learn, so that's a plus.  But it's still very tedious to get all the
> parentheses matched up just right.

It seems that many (most?) people who actually try to write lisp
without making a big issue of the parentheses, very rapidly come to a
conclusion that disagrees with yours.




[*]
I'm sorry, I can't remember what was concluded about new behaviour of
Python in this respect (and I only have access to 1.5 at present :-(